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?