Re: [PATCH, middle-end - RTL]: scheduling, UNSPEC_VOLATILEs should also represent insn blockage for insns with mem only operands

[Uros Bizjak <ubizjak at gmail dot com>]

Ian Lance Taylor wrote:

> > > I think the question here is whether an UNSPEC_VOLATILE should always
> > > be a memory barrier.  A volatile asm is not a memory barrier unless it
> > > has an explicit clobber of "memory".  It's reasonably easy to make any
> > > instruction which uses UNSPEC_VOLATILE be a memory barrier by adding
> > > (clobber (mem:blk (scratch)).
> > >   
> > >       
> > There is a comment just below the area my patch touches:
> >
> >    /* Traditional and volatile asm instructions must be considered to use
> >       and clobber all hard registers, all pseudo-registers and all of
> >       memory.  So must TRAP_IF and UNSPEC_VOLATILE operations.
> >
> >       Consider for instance a volatile asm that changes the fpu rounding
> >       mode.  An insn should not be moved across this even if it only uses
> >       pseudo-regs because it might give an incorrectly rounded result.  */
> >     
>
> Despite that comment, I believe that we do currently permit moving
> instructions which only have memory operands across volatile asm
> instructions which do not explicitly clobber memory.
>
> If you want UNSPEC_VOLATILE and volatile asm instructions to act the
> same way, then your patch is incomplete, since it only changes the
> behaviour of UNSPEC_VOLATILE.
>   

This was in fact done intentionally. I think that inside volatile asm 
statements, it is quite well described, what the statement is doing, and 
adding memory to the list of clobbers intuitively follows this 
description. OTOH, the unspec_volatile instructions are modelling 
something that can't be well described, i.e. the instruction changes 
some global machine state that isn't modelled in the machine description.

Also, there are practically no instructions that have only memory 
operands and do not touch registers at all - I didn't found other than 
memory_barrier ATM. Due to this fact, I think that by treating 
unspec_volatiles as memory-clobbering we loose nothing, but we introduce 
some determinism into memory ordering.
> That is a good argument.  Also, it's possible that for this purpose we
> should distinguish between
>     (unspec_volatile ...)
> and
>     (set (...) (unspec_volatile ...)
> I'm not sure.
>   

IMO, due to the fact that unspec_volatiles are already the schedule 
blocking point for practically all instructions, there is no need to 
complicate things any further.

Uros.