[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

amylaar at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Mon Apr 6 00:37:00 GMT 2009



------- Comment #25 from amylaar at gcc dot gnu dot org  2009-04-06 00:37 -------
(In reply to comment #24)
> Which testcase?

The second attachment, 20367-sched.c

>  This bug is mildly confusing.  Note that i is a global
> variable,

If you mean i in f of comment #2, that's not gloabal, but static.

> it may be reached via recursive invocations of the function and
> we do not have analysis that disproves this.

I suppose you mean that f may be reached via recursion, thus
clobbering i, as already mentioned in comment #7.

Unfortunately, the original testcase went into the big bit bucket in the sky,
and when you try to make up a minimal example on the spot, you are bound to
overlook the very same aspects of the problem you have overlooked in the
work on the problm so far.

But there is still code in EEMBC that genuinely benefits from load hoisting /
store sinking and scheduling which is enabled by recognizing that a static
variable that hasn't got its address taken can't alias another MEM - in some
cases, the static variable can be completely replaced by a local variable,
in other cases, it can't (without whole-program analysis) because an
indirect recursive call cannot be ruled out.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367



More information about the Gcc-bugs mailing list