On Sat, Dec 19, 2009 at 10:50 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Fri, Dec 18, 2009 at 3:29 PM, Richard Guenther <rguent...@suse.de> wrote: >> >> This fixes one part of PR42108, the missed discovery of a full >> redundant load. The issue is that the SSA SCC value-numberer >> does not visit loads and stores in a defined order. The (or rather >> one) fix is to properly canonicalize the virtual operand SSA names >> we record in the expression hash tables. The proper canonical >> virtual operand is the def of the first dominating may-definition >> (or a PHI node vdef, but we can as well choose a non-may-definition >> without loss of precision and generality). >> >> The patch possibly slows down SCCVN a bit for examples like >> >> # .MEM_2 = VDEF <.MEM_1(D)> >> may-def >> .... >> # VUSE <.MEM_120> >> ... = X; >> # VUSE <.MEM_120> >> ... = X; >> >> where discovering the redundant load of X needs to canonicalize >> their VUSE SSA name twice (previously we entered the expression >> into the hashtable with .MEM_120 so it would be found immediately). >> Now if we had >> >> # VUSE <.MEM_60> >> ... = X; >> >> inbetween the may-def and the other loads we previously discovered >> the full redundancy only if we first visited the load with .MEM_60 >> and only after that the loads with .MEM_120. But nothing guarantees >> this - this is the case the patch fixes. There are about 0.5% >> more redundant loads discovered in tramp3d with this patch. >> >> This is a regression of the alias-improvements branch merge as >> previously we had different virtual operands and thus in more >> cases the canonical vuses were automagically chosen. >> >> Bootstrapped and tested on x86_64-unknown-linux-gnu. I have patched >> one of our SPEC / C++ testers for more testing coverage. >> > > This may have caused: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42435 >
This also caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279 -- H.J.
