http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rakdver at gcc dot gnu.org
--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-02
13:33:21 UTC ---
It's not easy to detect this situation from IVOPTs (well, conservatively
at least). Given that this is another case of alias analysis being
confused (TMR[&p1 + ivtmp] does not refer to object p1), dumbing down
that analysis would seem like a "solution" to this issue ... :/
That's of course not a sustainable approach ...
pointer analysis on MEM[symbol: p1, index: ivtmp.161_200, offset: 0B]
would figure that &p1 + ivtmp.161_200 also points to NONLOCAL, not only
to p1, but we do not have a SSA name to store points-to info in this
case (one more argument against TARGET_MEM_REF and an argument for
more complex address-computation trees instead). Thus we'd for now
have to assume that a TARGET_MEM_REF points to anything ... that's
pretty bad for RTL optimization, for exactly which we improved alias
analysis for TARGET_MEM_REF in the first place.
Hum.
The issue only pops up because of the ->consider_all_candidates path.
Otherwise we do not apply this awkward choice.
Thus you can avoid the issue by --param iv-consider-all-candidates-bound=1.
Maybe we shouldn't really consider _all_ candidates, but only all bivs?
