On January 31, 2015 4:07:23 AM CET, Segher Boessenkool <seg...@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
