Re: [4/4][PATCH] Discussing PR83507

2019-04-30 Thread Jeff Law
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”

Re: [4/4][PATCH] Discussing PR83507

2019-04-30 Thread Roman Zhuykov
> > > 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

Re: [4/4][PATCH] Discussing PR83507

2019-04-29 Thread Segher Boessenkool
Hi! On Mon, Apr 29, 2019 at 07:28:12PM +0300, Roman Zhuykov wrote: > > 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,

Re: [4/4][PATCH] Discussing PR83507

2019-04-29 Thread Roman Zhuykov
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

Re: [4/4][PATCH] Discussing PR83507

2019-04-23 Thread Segher Boessenkool
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

Re: [4/4][PATCH] Discussing PR83507

2019-04-22 Thread Roman Zhuykov
> > This issue unfortunately was not solved correctly. In that example we > > don’t have -fmodulo-sched-allow-regmoves enabled and we should not > > create any register moves at all. > > Yes, but if we do for whatever reason, we should never create register > moves of hard registers. Because

Re: [4/4][PATCH] Discussing PR83507

2019-04-16 Thread Segher Boessenkool
On Tue, Apr 16, 2019 at 03:08:23PM +0300, Roman Zhuykov wrote: > This issue unfortunately was not solved correctly. In that example we > don’t have -fmodulo-sched-allow-regmoves enabled and we should not > create any register moves at all. Yes, but if we do for whatever reason, we should never

[4/4][PATCH] Discussing PR83507

2019-04-16 Thread Roman Zhuykov
This issue unfortunately was not solved correctly. In that example we don’t have -fmodulo-sched-allow-regmoves enabled and we should not create any register moves at all. I’ll describe here everything I found while looking on the issue. At the first step I have patched trunk compiler like