------- Comment #5 from wilson at gcc dot gnu dot org 2010-05-17 20:24 -------
A little more debugging. I traced through the true_dependence call that is
returning 0 when it should return 1.
We end up calling rtx_refs_may_alias_p at the end. This calls
refs_may_alias_p_1, which calls indirect_ref_may_alias_decl_p which discovers
that we have different non-overlapping alias sets, and it declares that there
is no aliasing here. This is last-resort TBAA being used here.
We have different alias sets, because one reference is to
... arg 0 <var_decl 0xb7d4eba0 vtab$s_bar
type <record_type 0xb7d4ea80 vtype$s_bar BLK ...
and the other is to
... arg 0 <indirect_ref 0xb7d74c94
type <record_type 0xb7d4e060 vtype$foo BLK ...
It appears that the Fortran front end is deliberately confusing the types here,
because in the .003t.original dump file I see
a.$vptr = (struct vtype$foo *) &vtab$s_bar;
a.$data = (struct foo *) &c;
a.$vptr->doit (&a);
So either the fortran front end needs to get the types right, or else the
fortran front end needs to explain to the alias code that these apparently
unrelated types do alias. Or maybe the alias code needs to be extended to
recognize Fortran OOP types that can alias each other. I didn't look at this.
Along the way, I did discover another place where it appears that we can solve
the problem. After the get_addr calls in true_dependence, we have
mem_addr
(if_then_else:DI (eq (value:BI 58:4011 @0x8b22b50/0x8b360e0)
(const_int 0 [0]))
(plus:DI (value:DI 55:2108434270 @0x8b22b2c/0x8b3608c)
(const_int 24 [0x18]))
(value:DI 57:57 @0x8b22b44/0x8b360c4))
insn 103
x_addr
(plus:DI (value:DI 55:2108434270 @0x8b22b2c/0x8b3608c)
(const_int 24 [0x18]))
These addresses obviously conflict. Unfortunately, neither memrefs_conflict_p
nor rtx_equal_for_memref_p have any support for if_then_else inside an address.
If one of them was modified to check for an if_then_else and then recursively
compare against both arms of the if_then_else, then that would solve the
problem too. This would prevent us from falling through to the last-resort
TBAA code that isn't work as desired here.
I'm not planning to do any other work on this in the short term, as I have
other IA-64 problems I need to try to fix first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
