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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Uros Bizjak <ubizjak@gmail.com> writes:
> 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.

Probably not a helpful contribution, sorry, but I don't think the
comment can be taken literally in any case.  If we assumed that
UNSPEC_VOLATILE could clobber all hard registers, any function that
contains an UNSPEC_VOLATILE would need to save and restore all
call-saved registers.  We don't do that at present.

OTOH, I think they really are supposed to be complete scheduling
barriers.  Following on from what you said about GP, traditional MIPS
code uses assembly macros for symbolic accesses.  When GCC generates
this kind of code, symbolic instructions might have implicit GOT uses,
and we have traditionally assumed that the scheduler will move no such
instructions past the UNSPEC_VOLATILE set of GP.  From that POV, I think
any example of the scheduler moving an instruction past an UNSPEC_VOLATILE
is a bug.

Richard