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

Uros Bizjak ubizjak@gmail.com
Mon Dec 29 15:49:00 GMT 2008


Ian Lance Taylor wrote:
> Uros Bizjak <ubizjak@gmail.com> writes:
>
>   
>> Attached patch teaches scheduler to flush pending lists of memory
>> loads and stores for UNSPEC_VOLATILEs, preventing insns that have only
>> memory operands to pass UNSPEC_VOLATILE insns.
>>     
>
> 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.  */

The documented and recommended way to implement blockage insn is:

`blockage'
     This pattern defines a pseudo insn that prevents the instruction
     scheduler from moving instructions across the boundary defined by
     the blockage insn.  Normally an UNSPEC_VOLATILE pattern.

At the moment, implementation of blockage with UNSPEC_VOLATILE prevents 
scheduler from moving instructions that reference registers, but 
instructions that reference only memory operands are still free to pass 
the blockage point.

> My inclination would be to say that UNSPEC_VOLATILE is more or less
> equivalent to a volatile memory read: that it is not, by itself, a
> memory barrier.  I would be happy to hear other opinions.
>   

Please consider an insn that modifies GP register, as is the case with 
alpha. Changing the GP IMO invalidates all memory reads and writes.

Uros.



More information about the Gcc-patches mailing list