[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