Alias set coverage issues (Was: Re: RFA: Fix rtl-optimization/57425)

[Joern Rennecke <joern dot rennecke at embecosm dot com>]

Quoting Eric Botcazou <ebotcazou@adacore.com>:

> > Bootstrapped/regtested on i686-pc-linux-gnu.
>
> For the record, and as you diagnosed, the change proposed in
>   http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00367.html
> means that we must now be very careful with memory dependency checking in the
> various RTL optimization passes.  Another example is PR rtl-opt/57569.

[subject / list changed because this goes off on a tangent]

I have set out here to just fix the problem at hand, but it is a bit
worrying that cse is about to replace a read with a copy of a value read
before using an alias set that is not considered compatible.
It would be OK if the alias set of the re-used read was adjusted, but I don't
think we have any such code in cse.
In this case, avoiding an invalid transformation (due to anti-dependency)
avoids further complications from the alias sets, but what if we had
a more complex case?  Could we end up with a non-matching write/read pair
that can be re-ordered by subsequent passes?  It couldn't be for sharing
a previous stack-slot like in the test cases here, since then we would
have to have an uninitialized read or overlapping lifetimes to start with,
but maybe it could happen when using union member/aliased read accesses
with use that depends on a discriminator?
The thing is, when it comes to alias set issues, very seldom is it true that
everything that can go wrong, does.  Michael Matz shuffle mode would go
some way to address this, but it still would provide poor coverage when
we need to take a specific path on a long Markov chain to see a problem.

Now, if we had an rtl interpreter that can be invoked in addition to/instead
of a dump generation with specific options, and this interpreter not only
kept track of values being initialized (as valgrind does), but actually
kept track of the alias of the last write for each addressable unit, and
checked the compatibility of the alias set on read, we'd have a powerful
tool to both add new regression tests, and to help during debugging where
the compiler goes wrong, or for a user, to check if his/her code contains
alias set problems.
Would this be suitable for a GSOC project?
It would already be useful if it worked just for self-contained tests,
although obviously the utility would increase if it could dynamically load
other object files (with name mangling?) to complete a multi-module test case.