On Wed, Jun 12, 2013 at 1:15 AM, dw <limegreensocks@xxxxxxxxx> wrote:
>>> 1) Am I right that __builtin_ia32_mfence() does not generate a memory
>>> barrier?
>
>
>> That is correct: it does not prevent the compiler from moving loads
>> and stores across the call to __builtin_ia32_mfence.
>
>
> Are you sure? Based on your comment, I was fully expecting to be able to
> produce a failure case suitable for bugzilla.
No, I'm not sure.
> In fact, I *can* generate failure cases if I comment the
> __builtin_ia32_mfence() call out of _mm_mfence and replace it with something
> else (like asm("mfence")). But as soon as I put the __builtin_ia32_mfence
> call back in, my "failure scenario" clears right up.
>
> In short, it looks like __builtin_ia32_mfence *does* generate a barrier.
> But so do other builtins (like __builtin_ia32_pause). Does that even seem
> possible? It would be weird if every builtin (or even every ia32 builtin)
> implied a barrier.
As far as I know, __builtin_ia32_mfence does not generate a barrier.
However, what it does do is appear to be a function call to the main
optimization stages of the compiler. This is not true of an asm
statement, nor of an inlined function. The __builtin_ia32_mfence call
is only expanded to an instruction when GCC converts to RTL, after the
main optimizations have been run. However, it is still possible for
memory loads and stores to move after RTL, specifically when doing
register allocation and spilling register loads and stores to the
stack.
So when I say that as far as I know __builtin_ia32_mfence does not
generate a barrier, what I mean is that as far as I know after it is
expanded to RTL there is no barrier. But I could be wrong.
Ian
