https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91571
Bug ID: 91571
Summary: TBAA does not work for ao_ref created by
ao_ref_init_from_ptr_and_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
Given a SSA_NAME pointer, its type information is discarded by
ao_ref_init_from_ptr_and_size() when building an ao_ref from the pointer, thus
TBAA for this kind of ao_ref is actually disabled. Related code snippet:
else
{
gcc_assert (POINTER_TYPE_P (TREE_TYPE (ptr)));
ref->base = build2 (MEM_REF, char_type_node,
ptr, null_pointer_node);
......
}
.....
ref->ref_alias_set = 0;
ref->base_alias_set = 0;
If enabled, some optimizations relying on this could produce better result.
Here is an example for IPA-CP, but not just it (others include dse,
strlen-opt).
struct A
{
int a;
};
struct B
{
int b;
};
void f2 (struct A *pa, struct B *pb)
{
...
}
void f1(int v, struct A *pa, struct B *pb)
{
pa->a = 1;
pb->b = v;
f2 (pa, pb);
}
The ao_ref for f2's argument "pa" is setup by ao_ref_init_from_ptr_and_size(),
AA can not disambiguate pa->a and pb->b due to loss of original type
information, and IPA-CP gets a conservative conclusion that constant "1"
assigned to pa->a can not reach f2(pa, pb), then misses a chance of constant
propagation.
I check uses of ao_ref_init_from_ptr_and_size(), it is mainly used in alias
analysis on function call arguments. That's better to enable TBAA in this
scenario, but not sure is there any special consideration about it?
