The discussion below assumes 64bit code on an i386 processor.
My understanding is that the way to do a memory barrier in gcc is:
asm ("" ::: "memory");
This creates a ReadWriteBarrier, but no processor fence. To create a
processor fence, you could do something like
__builtin_ia32_mfence();
This will generate an mfence instruction, but (assembly code inspection
suggests) no memory barrier. I thought about just putting one after the
other:
asm ("" ::: "memory");
__builtin_ia32_mfence();
And this leads to my questions:
1) Am I right that __builtin_ia32_mfence() does not generate a memory
barrier?
1) Is this "two statement thing" guaranteed to be safe? Could the
optimizer re-order instructions moving code in between the two? (Yes, I
realize that the asm statement doesn't actually generate any output.
But given my understanding of how the compiler processes code, I believe
the question is still valid).
2) If it is not guaranteed to be safe, what is the use of
__builtin_ia32_mfence()? What value is there in preventing the
*processor* from executing statements out of order if the *compiler* is
just going to move them around?
I expect this would always work:
asm ("mfence" ::: "memory");
But I would rather use the builtins if possible.
dw
