lra incorrectly reloading scratch for a memory barrier?

[Segher Boessenkool]

On Fri, Jan 30, 2015 at 12:50:01PM -0800, Richard Henderson wrote:
> >> Jakub, the current formation includes both a use and a set of all
> >> memory.  Your
> >> clobber form would not imply a use.
> > 
> > What do you need the use for? Prevent all DSE before the barrier for some weird reason?
> 
> I don't consider the clobber to be accurately representational of a barrier.
> It may work by accident, because the scratch address prevents aliasing
> disambiguation, but I don't think it's good form.

alias.c says:

  /* (mem:BLK (scratch)) is a special mechanism to conflict with everything.
     This is used in epilogue deallocation functions, and in cselib.  */

so it is not an accident?  You added it yourself, back in 2002 :-)
The commit message mentions PR6165, which leads us to
http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00231.html

> If we were talking about a register and not memory, the clobber would not
> prevent movement of a store across the barrier.

Because registers do not live in memory (as far as GCC knows, anyway)?  You
can also clobber some specific mem, and that does prevent movement of any
store to (or read from) that mem over the clobber.

> Do we really want different
> rules for (mem (scratch)) than other rtl objects?

It is quite similar to related things, in most ways (even the "scratch" part
reads similar to "(clobber (scratch))").

There is nothing else that will give these semantics.  We could invent a
new RTL code, with the only effect that we would need to check for more
codes in more places -- there aren't many places that need to check for
this merely to exclude it.


Segher