Messages in this thread | | | Date | Tue, 03 Jul 2012 11:08:14 +0100 | From | "Jan Beulich" <> | Subject | Re: __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
| |