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

H. Peter Anvin
2010-07-15T05:00:15Z

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