Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock

[H. Peter Anvin]

On 07/14/2010 11:11 PM, Jeremy Fitzhardinge wrote:
> The question is "what are the real ordering semantics of asm volatile"?
> What ordering is enforced between other asm volatiles?  What ordering is
> enforced between asm volatiles and regular memory accesses? asm volatile
> and other code?
>
> The documentation discusses this to some extent, but mostly says "there
> are no ordering guarantees".  Older versions of gcc - 2.95, for example
> - are more explicit, saying that "asm volatiles" won't be moved out of
> their basic block (I think that's how I parse it, anyway).

I looked over the text, and I think you're confusing static reordering 
and duplication with execution reordering (gcc is indeed free to move 
around and even replicate asm volatile statements).  One thing is that 
the docs makes it perfectly clear that asm volatile is not ordered with 
respect to *non*-volatile operations (*all* the examples are 
volatile-nonvolatile.)  It says that asm volatile statements may not be 
"consecutive", i.e. gcc may generate code in between them, but all of 
this is well known and understood.

The other thing that the documentation *does* specifically make clear is 
that an "asm volatile" has an implicit dependency on all memory (as an 
input, as opposed to an output/clobber.)

I actually found the following statement in the gcc documentation, 
although it is in the section on C++ (6.1 in my version); the text, 
though, makes it clear that it applies to both C and C++:

Both the C and C++ standard have the concept of volatile objects.  These
are normally accessed by pointers and used for accessing hardware.  The
standards encourage compilers to refrain from optimizations concerning
accesses to volatile objects.  The C standard leaves it implementation
defined  as to what constitutes a volatile access.  The C++ standard
omits to specify this, except to say that C++ should behave in a
similar manner to C with respect to volatiles, where possible.  The
minimum either standard specifies is that at a sequence point all
previous accesses to volatile objects have stabilized and no subsequent
accesses have occurred.  Thus an implementation is free to reorder and
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
combine volatile accesses which occur between sequence points, but
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cannot do so for accesses across a sequence point.  The use of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
volatiles does not allow you to violate the restriction on updating
objects multiple times within a sequence point.

[My emphasis, obviously.]

I think that pretty much settles the matter, since any statement 
(including an asm statement) inherently has a sequence point before or 
after it.  However, I will file a gcc bug report to clarify.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/