[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #26)
> (In reply to Richard Biener from comment #25)
> > (In reply to Kewen Lin from comment #24)
[...]
> > Ah, probably the alias-set is determined from the unmangled ref ...
> > 
> > > Aggressively further hacking with attrs.alias =
> > > 0 can make it pass. Can we make an new alias set for each partition? then
> > > all involved decls in the same partition is aliased. For a particular
> > > involved decl, it's aliased to the previous ones and the new ones in its own
> > > partitions.
> > 
> > hmm, no - this won't work.  In fact even attrs.alias = 0 will probably
> > not work reliably since we can coalesce variables that escape and thus
> > the above will only alter accesses via the original decls but not any
> > accesses done via pointers.  So indeed any alias-set mangling is pointless
> > here.
> > 
> > Consider
> > 
> >  {
> >    A x;
> >    int * volatile p = &x;
> >    *p = 1;
> >    .. = *p;
> >  }
> >  {
> >    B y;
> >    float * volatile q = &y;
> >    *q = 1;
> >    .. = *q;
> >  }
> > 
> > if we coalesce x and y then we are not rewriting any accesses
> > but obviously the accesses still need to conflict - but the
> > indirect accesses will have their original non-conflicting alias-set
> > and thus the scheduler would be free to move the store to *q across
> > the load from *p (the "trick" would be to make an incentive to do so
> > of course).
> 
> Thanks for the clarification! Is it possible to update the alias set for the
> indirect accesses as well? since we know the address is originally taken
> from one coalesced decl (also update its propagated ones).

I suppose we could record a bitmap of all decls participating in any
coalescing, check whether a MEM could possibly refer to any of them
via the points-to API and then force alias-set zero for those.  We
could also try to do sophisticated analysis to make assigning a new
alias-set for each coalesce group work, merging groups when there's
indirect accesses that could alias a member of more than a single
group.

Note that the other bugs linked perform wrong coalescings (for things
which have overlapping life time) while this one performs coalescing
wrong (not properly adjusting accesses so they later conflict).