[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: lra incorrectly reloading scratch for a memory barrier?
From:       Richard Biener <richard.guenther () gmail ! com>
Date:       2015-01-31 8:51:44
Message-ID: 31EB17E3-3018-4BA2-8B49-CD032399F2C9 () gmail ! com
[Download RAW message or body]

On January 31, 2015 4:07:23 AM CET, Segher Boessenkool <segher@kernel.crashing.org> \
wrote:
> 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.

The only relevant thing is that aliasing cannot disambiguate the MEM that is \
clobbered.  Whether that's via using a scratch or some other means is not relevant.

Having a MEM use pessimizes code in addition to being a memory barrier.

Where memory barrier == scheduling barrier.

Richard.

> 
> Segher


[prev in list] [next in list] [prev in thread] [next in thread]