On Jan 16, 2013, Jakub Jelinek <jakub@redhat.com> wrote:

> for i686-linux tree-ssa-pre.o is different, and
> for x86_64-linux go/export.o is different.

I looked into the latter first, and that revealed a few major bugs:

1. I'd failed to fully implement what I'd planned.  The canonicalization
function would still take REGs from dataflow sets, instead of only
VALUEs that can be safely cached, and the memory clobbering was still
using an expression that could contain REGs rather than only VALUEs.
This means at times the canonical values could have been wrong, and they
could accidentally fail to match.

2. ENTRY_VALUEs, that could already be used as canonical base addresses
before, have now become far more likely to be chosen as such, but the
alias code compared all ENTRY_VALUEs of the same mode equal, because the
ENTRY_VALUE operand is a 0 rather than an e.

Having fixed these two problems, the debug info for go/export became
identical.  Feeling adventurous, I made all memory overlap tests
performed as part of the memory clobbering use (the nwo cheap)
canonicalized addresses, instead of only canonicalizing the compare-with
addresses that were marked as SP-based.

This gives us additional accuracy in the tests, and this caused some
additional differences in tree-ssa-pre compare on i686: with the earlier
patch, we'd fail to recognize many compares as non-overlapping, and
conservatively drop the corresponding MEMs from the dataflow set.  In
other cases, it was the use of VALUE-based address canonicalization that
enabled the mem conflict test to do a better job.

While investigating this, I found out we'd go TWICE over the entire
dataflow set clobbering each modified MEM, when once would have been
enough, and fixed that too.  This should further reduce the performance
impact caused by the original memory clobbering patch.

Here's the patch I've just regstrapped.  Test results look good, with no
regressions introduced since the earlier version of the patch, which
itself hadn't regressed on top of an earlier tree.  However, there are
regressions comparing the latest results with those based on the earlier
tree, so I'm now running a baseline test just to be sure that the
regressions are not caused by this patch.  Ok to install if they aren't?