On 4/29/19 10:28 AM, Roman Zhuykov wrote:
> Hi, Segher
>
>>>>> In pr84524.c we got a loop with an extended inline asm:
>>>>> asm volatile ("" : "+r" (v))
>>>>> which also gives us a “surprising” situation Alexander predicts.
>>>>>
>>>>> For sched-deps scanner such volatile asm is a “true barrier” and we
>>>>> create dependencies to almost all other instructions, while DF scanners
>>>>> don’t give us such information.
>>>>
>>>> There is no such thing as a "true barrier" in extended asm. The only thing
>>>> volatile asm means is that the asm has a side effect unknown to the
>>>> compiler;
>>>> this can *not* be a modification of a register or of memory contents, such
>>>> things are known by the compiler, that's what clobbers and "memory" clobber
>>>> are about.
>>>
>>> In sched-deps.c we got:
>>> case ASM_OPERANDS:
>>> case ASM_INPUT:
>>> {
>>> /* 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.
>>> */
>>> if ((code != ASM_OPERANDS || MEM_VOLATILE_P (x))
>>> && !DEBUG_INSN_P (insn))
>>> reg_pending_barrier = TRUE_BARRIER;
>>> ...
>>
>> This code was added in 1997 (r14770). In 2004 the documentation was
>> changed to clarify how things really work (r88999):
>>
>> "Note that even a volatile @code{asm} instruction can be moved relative to
>> other code, including across jump instructions."
>>
>> (followed by an example exactly about what this means for FPU control).
>
> Thanks for pointing to that changes! Unfortunately, sched-deps.c was
> more conservative this 15 years...
> Let’s try to fix it.
Also note that the integration of the Haifa scheduler was a large
change. A small detail like this could have been missed.
Jeff
