lkml.org 
[lkml]   [2010]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
    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


    \
     
     \ /
      Last update: 2010-07-15 07:03    [W:0.028 / U:34.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site