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

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

[Joern Rennecke]

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.

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

[Eric Botcazou]

> 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.

I don't think that's a problem, as the second read must be done with an 
appropriate type in order to be valid if there is no intervening write.

> 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?

I'd think that the latest RTL aliasing model is conservative enough as to be 
safe (modulo bugs) but these are IMO legitimate questions whose answer is not 
immediate, so it would be nice to have a summary written down somewhere, and 
that would probably be at the beginning of alias.c.

Michael, would you mind writing down one as a follow-up to the stack slot 
sharing patch when you have some time?  The patch effectively breaks long-held 
assumptions in RTL alias analysis, so that would really help.  TIA.

> 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?

I don't know, that seems to be a bit daunting for a GSOC project.

-- 
Eric Botcazou