https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #38 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #37)
> (In reply to rguent...@suse.de from comment #36)
>
> > Note that the only thing we have to do is fix points-to info, the TBAA
> > info should be correct and OK even when objects share location, so there's
> > nothing we can do at RTL expansion time.
>
> I haven't really studied the way the TBAA code works before, so I may have
> missed something, but we clearly end up creating two MEMs for the same
> location with non-conflicting alias sets. So perhaps the problem is when we
> assign the alias set when we create the MEM (it's taken from the original
> type, without regard to the stack slot assignment).
>
> What would be in the TBAA code to prevent
>
> struct A
> {
> int a[4];
> };
>
> struct B
> {
> float b[4];
> };
>
> struct A x;
> struct B y;
>
> f ()
> {
> struct A m;
> struct B n;
> ...
> x = m; // m dead
> n = y; // n born
> ...
> }
>
> from moving these two assignments past each other at the RTL level if they
> shared the same stack slot?
There's a WAR dependence between those assignments. Write-after-read is
not allowed to use TBAA in our memory model (likewise write-after-write),
only read-after-write is.
One side-effect of this is that "redundant stores" (redundant in terms of
that the second store does not change any bits in the memory location)
are not always "redundant" with respect to the memory model. Currently
we have to preserve those, their effect is to change the effective type
of the memory location for downstream reads.
There's a (maybe too short) documentation about our TBAA memory model
in tree-ssa.texi at the very end.
