http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vries at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-20
10:12:35 UTC ---
It's the tail-merging value-numbering doing
Value numbering .MEM_8 stmt = b_9 = malloc (12);
Setting value number of .MEM_8 to .MEM_8 (changed)
Setting value number of b_9 to b_9 (changed)
SCC consists of: .MEM_11
Value numbering .MEM_11 stmt = b_12 = malloc (12);
Setting value number of .MEM_11 to .MEM_8 (changed)
Setting value number of b_12 to b_9 (changed)
SCC consists of: b_12
which is of course bogus. The pointers do not share the same alias
properties and thus when disambiguating *b_12 against setb (b_12)
which uses the call-clobbered vars set of the gimple call it doesn't
work if you instead ask it to disambiguate *b_9.
I know that I was nervous about this change ... it basically value-numbers
the result of non-const/pure calls using the same VUSE the same. That's
broken if the IL contains bits that rely on the results being distinct
(which is alias information when it comes to malloc-like results).
In theory alias info of value-equivalent SSA names can be _intersected_
to get the alias info of the value. Now in this case alias info computation
relies on the fact that the calls are different - which means alias info
for those "equivalent" SSA names has to be _unioned_. All of this
alias-info adjusting doesn't work during the value-numbering process
though, so it's not an option to do it as a post-processing step.
We rely on the intersection property with all the value-numbering to not
need to do any alias-info adjusting - but getting the unioning requirement
in via value-numbering those calls the same breaks this.
Which means the most obvious "fix" is to not value-number those calls the
same.
