_mm_sfence and memory barriers

[David_W_11]

In another thread in this forum (http://software.intel.com/en-us/forums/topic/305582), there was a comment:

The _mm_?fence thererfor serves to purposes: 1) inform the compiler of the requirement of pending reads or writes not to be moved before or after the specified fence statement. And 2) the compiler is to insert an appropriate processor fence instruction, or lacking that a function call to perform the equivilent fencing behavior.

My question is, is there an authoritative source for #1?  I have yet to find a credible reference that says that _mm_mfence generates a compiler ReadWriteBarrier.

[David_W_11]

Just to wrap this up...

The implementations of the _mm_?fence instructions are all compiler specific.  Whether they correctly perform barriers is dependent on the compiler implementation:

• gcc performs the barriers for fences (see the thread at http://gcc.gnu.org/ml/gcc-help/2013-06/msg00086.html). ; It appears that all fence instructions implicitly do a _readwritebarrier().
• MS just responded today (8 months later), and they also correctly do barriers for fences (see https://connect.microsoft.com/VisualStudio/feedback/details/790233/mm-mfence-needs-to-perform-implicit-readwritebarrier). ; Their response indicates that they do the appropriate type of barrier for each fence.
• intel has never responded to my requests for information, so I do not know what their compiler does.

I post this here in case some future google search sends someone here.

FWIW

[SergeyKostrov]

>>...The implementations of the _mm_?fence instructions are all compiler specific... Sorry, No. The same instructions are used. However, Not every C/C++ compiler supports it. For example, in case of a legacy Turbo C++ v3.x ( 22 year old ) compiler I use the following piece of code: ... //*** Irt?fence ***// #define IrtSfence() { __emit__( 0x0F, 0xAE, 0xF8 ); } #define IrtLfence() { __emit__( 0x0F, 0xAE, 0xE8 ); } #define IrtMfence() { __emit__( 0x0F, 0xAE, 0xF0 ); } ...

[David_W_11]

Hello Sergey.

Had I said "the implementations of SFENCE are all compiler specific", you would have been correct.  But _mm_sfence can (and sometimes does) perform implicit barriers IN ADDITION to emitting the SFENCE opcode.

Whether a compiler does that while processing the _mm_sfence is a decision that only the compiler can make.

For that reason, I stand by my statement that "The implementations of the _mm_?fence instructions are all compiler specific." 

[JenniferJ · Accepted solution]

DavidW and all,

The Intel Compiler treats the _mm_mfence, _mm_lfence, and _mm_sfence intrinsics as ReadWriteBarrier, ReadBarrier, and WriteBarrier, respectively. Hope this clears any confusions.

Thanks,

Jennifer

[David_W_11]

Hey Jennifer, thanks for the reply.  Sorry my response is so delayed, but I never received a notice you had posted.

This is exactly the information I needed, as well as the answer I hoped for.  I thank you for clarifying this very obscure point.

While in retrospect it might seem like this was the only possible answer, the docs on this point are not as clear as they could be (hint, hint).  And sometimes unclear specs result in unexpected behavior.  But fortunately that wasn't the case this time.