https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Alexander Monakov from comment #8)
> > We need a solution that works for combine too — is it possible to invent a
> > representation for a no-op in-place MEM "move" that only changes its alias
> > set?
>
> That is the same as my comment here:
> > I don't know what is the best way to represent an aliasing set change
> > even though the value didn't change on the RTL level.
>
> Clobber might work though I don't know if that is 100% correct as the value
> didn't change so maybe a new RTL code for this? But that would require many
> changes in the backend ...
We need something similar on GIMPLE but I have not yet made up my mind
for something "nice" either ... I'm leaning towards something similar
to a CLOBBER on GIMPLE since that allows us to simply preserve the LHS,
so ...
MEM[(long int *)_11] = {NOOP};
but we have to make sure this isn't perceived as KILL for DSE purposes
though it does have KILL semantics otherwise (it needs to be a barrier
for load motion). DSE could of course replace the RHS when eliding an
earlier store.
On RTL a CLOBBER would have the same problem (with DSE), so maybe it
should be a
(parallel
[(use (MEM ...))]
[(clobber (MEM ...))])
? That's also the alternative on GIMPLE - have it be
MEM[(long int *)_11] = MEM[...];
with the caveat (same as above) of breaking the register typed temporary
rule.
On RTL other unwanted side-effects would be that register allocation
and scheduling have to handle the address compute of the MEM unless
we cobble up everything not allocated into a complex expression and
not require those MEMs to be recognized ...
