Re: [PATCH] x86: work around clang IAS bug referencing __force_order

[Arvind Sankar]

On Thu, Aug 20, 2020 at 12:44:06PM +0200, Thomas Gleixner wrote:
> On Thu, Aug 13 2020 at 14:09, Arvind Sankar wrote:
> > On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote:
> >> > Let me ask (hopefully) useful questions this time:
> >> > 
> >> >   Is a compiler allowed to reorder two 'asm volatile()'?
> >> > 
> >> >   Are there compilers (gcc >= 4.9 or other supported ones) which do that?
> >> 
> >> I would hope that the answer to both of these questions is "no"!
> >> 
> >> But I freely confess that I have been disappointed before on this sort
> >> of thing.  :-/
> >> 
> >> 							Thanx, Paul
> >
> > Ok, I found this, so gcc developers consider re-ordering volatile asm
> > wrt each other a bug at least.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
> 
> Yes. It prevents reordering of volatiles, but it does not necessarily
> prevent reorder of something like this:
> 
>         asm volatile(...);
>         foo();
>         asm volatile(...);
> 
> it might turn that into
> 
>         foo();
>         asm volatile(...);
>         asm volatile(...);
> 
> if I understood their discussion correctly. So removing this magic is
> not really straight forward.
> 
> Thanks,
> 
>         tglx
> 
> 

I don't think that's an issue, or at least, not one where force_order
helps.

If the source for foo() is not visible to the compiler, the only reason
force_order prevents the reordering is because foo() might have
references to it, but equally foo() might have volatile asm, so the
reordering isn't possible anyway.

If the source is visible, force_order won't prevent any reordering
except across references to force_order, but the only references are
from the volatile asm's which already prevent reordering.

I think force_order can only help with buggy compilers, and for those it
should really have been an input-output operand -- it wouldn't currently
do anything to prevent cr writes from being reordered.

Thanks.