Hi Roman, On Mon, Apr 22, 2019 at 07:36:40PM +0300, Roman Zhuykov wrote: > > > 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). > I understand that mentioned “changing fpu rounding mode” example may > not be relevant in current compiler. But we still got TRUE_BARRIER > for all volatile asms. > > > Maybe it is a good idea somehow re-implement modulo scheduler using only > > > one scanner instead of two, but at the moment the best thing to do is to > > > detect the situation earlier and skip such loops. > > > > Or fix the broken code... > > I’m not sure what you mean here, I mean have the modulo scheduler implement the correct asm semantics, not some more restrictive thing that gets it into conflicts with DF, etc. I don't think this will turn out to be a problem in any way. Some invalid asm will break, sure. Segher