http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |50067
--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-28
14:32:58 UTC ---
The issue is that we want to disambiguate a[i].f1 and a[i].f2, so for the
"base object" we zero out all known indices, resulting in a[0].f1 and a[0].f2
which we then disambiguate (and conclude that for all i there cannot be
a dependence).
Now, when we mix pointer accesses with array accesses most of the index
analysis falls apart (which is what the fix for PR50067 tries to make
work more reliably - see its comment #13 on the dr_may_alias_p issue ...)
So, it's really wrong to try to fixup DR_BASE_OBJECT to make dr_may_alias_p
work, and it is equally wrong to use DR_BASE_OBJECT in dr_may_alias_p.
Using DR_REF (a safe bet) falls foul of failing a load of testcases, for
example gcc.dg/vect/pr37027.c which is no longer vectorized because
(compute_affine_dependence
stmt_a: D.1722_7 = a[i_24].f1;
stmt_b: D.1725_11 = a[i_24].f2;
) -> dependence analysis failed
previously we'd have used a[0].f1 and a[0].f2 in the disambiguation in
dr_may_alias_p and disambiguated the accesses.
We can try a similar trick as with REALPART/IMAGPART_EXPR to recover this.
Add a constant access function for outer COMPONENT_REFs (those we can strip
off the base object).
