lkml.org 
[lkml]   [2012]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: __force_order usage on x86's CRn accesses
    >>> On 03.07.12 at 11:55, Glauber Costa <glommer@parallels.com> wrote:
    >> Furthermore, the addition of these constraints happened
    >> without any real explanation - the code comment that was added
    >> doesn't really help understand why "volatile" isn't sufficient here.
    >
    > If my memory dont't fail me, I believe this is because gcc will feel
    > free to reorder a sequence of instructions that does not access memory.
    > Specially since it has no knowledge of what's in the inline assembly,
    > and what are its constraints. It only knows that it is an register
    > operation, and treats it like one.
    >
    > Also, I believe what we are concerned with here is not arbitrary reorder
    > between that and other instructions, which we welcome, but reordering
    > between a read and a write to the same crX - specially of concern for
    > things doing read-modify-writes of control registers.

    But such sequences can't be re-ordered when the asm-s are
    volatile qualified.

    >> Finally (and this is because I lack the explanation why the
    >> artificial constraint is needed in the first place), why is it that
    >> clts() doesn't need one too?
    >>
    >
    > Because we're not using it to do read-modify-write of the control register.

    Sequences of read_cr0()/clts()/write_cr0() certainly exist (in
    the xor implementations), so if a read_cr0()/write_cr0() can
    have issues (which is impossible if the value written depends on
    the one read), read_cr0()/clts() would be even more affected,
    as there's no compiler visible dependency between the two.

    But I don't think any such can happen in reality, and I was
    hoping to be provided with an example of proving me wrong
    (and understand the whole situation).

    Jan



    \
     
     \ /
      Last update: 2012-07-03 13:01    [W:5.040 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site