Re: __force_order usage on x86's CRn accesses

["Jan Beulich" <JBeulich@suse.com>]

>>> 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