On 01/30/2015 12:40 PM, Richard Biener wrote: > On January 30, 2015 9:18:57 PM CET, Richard Henderson <r...@redhat.com> wrote: >> On 01/30/2015 12:12 PM, Mike Stump wrote: >>> On Jan 30, 2015, at 9:52 AM, Jakub Jelinek <ja...@redhat.com> wrote: >>>> On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: >>>>> I have a port that has: >>>>> >>>>> (insn 47 46 48 18 (parallel [ >>>>> (unspec_volatile:DI [ >>>>> (const_int 128 [0x80]) >>>>> (const_int 6 [0x6]) >>>>> ] UNSPECV_SPECIAL_OP) >>>>> (set (mem/v:BLK (scratch:DI) [0 A8]) >>>>> (unspec:BLK [ >>>>> (mem/v:BLK (scratch:DI) [0 A8]) >>>>> ] UNSPEC_MEMORY_BARRIER)) >>>> >>>> Why don't you just (clobber (mem/v:BLK (scratch:DI))) instead >>>> of the second set in the parallel? The instruction is already >>>> UNSPEC_VOLATILE, and to make the barrier effect clear a clobber >> should be >>>> sufficient. >>> >>> So, f087d65d84655bc2d5fdd4bcc6bf0fe337a39893 seems to have introduced >> the current way that all the ports do this currently. So, I’d leave >> this to Richard to answer. >>> >>> If (clobber (mem/v:BLK (scratch:DI))) works, certainly that seems >> simpler than what people do now, but, then I’m left wondering, why >> didn’t we do that from that start? >>> >> >> 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. If we were talking about a register and not memory, the clobber would not prevent movement of a store across the barrier. Do we really want different rules for (mem (scratch)) than other rtl objects? r~
