search for: _mm_mfence

Owen Anderson wrote: > Is this actually the case? I can't find it documented anywhere on > MSDN or the rest of the internet. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F MemoryFence WinNT.h 2231:#define MemoryFence _mm_mfence C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F MemoryBarrier WinNT.h 2288:#define MemoryBarrier __faststorefence 3362:MemoryBarrier ( 4890:#define MemoryBarrier __mf Also, I have absolutely no problem using MSDN search to find these links: http://blogs.msdn.com/itg...

Is this actually the case? I can't find it documented anywhere on MSDN or the rest of the internet. --Owen On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the

...ine void llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in <windows.h> and (since it's a preprocessor macro, and not a scoped function definition) causes the sys::MemoryFence definition on Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl intrinsic (_mm_mfence). This breaks the Visual Studio build. The trivial fix is to #undef MemoryFence immediately after including <windows.h>, since it's clearly assumed not to exist. A deeper and safer fix might consider avoiding a name conflict with a core system macro on a widely used platform. On May 17...

On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads! I'm not trying to make it required. I had provided

...MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl > intrinsic (_mm_mfence). This breaks the Visual Studio build. > > The trivial fix is to #undef MemoryFence immediately after including > <windows.h>, since it's clearly assumed not to exist. A deeper and > safer fix might consider avoiding a name conflict with a core system > macro on a widely us...

...r a locked top-of-stack idempotent operation is better than mfence). Other languages have private stacks where this isn't an issue, and where the stack top can reasonably be assumed to be in cache. *How will this affect non-user-mode code (i.e. kernel code)?* Kernel code still has to ask for _mm_mfence if it wants mfence: C11 and C++11 barriers aren't specified as a specific instruction. *Is it safe to access top-of-stack?* AFAIK yes, and the ABI-specified red zone has our back (or front if the stack grows up ☻). *What about non-x86 architectures?* Architectures such as ARMv8 support no...

...an mfence). Other > languages have private stacks where this isn't an issue, and where the > stack top can reasonably be assumed to be in cache. > > > > > > *How will this affect non-user-mode code (i.e. kernel code)?* > > > > Kernel code still has to ask for _mm_mfence if it wants mfence: C11 and > C++11 barriers aren't specified as a specific instruction. > > > > > > *Is it safe to access top-of-stack?* > > > > AFAIK yes, and the ABI-specified red zone has our back (or front if the > stack grows up ☻). > > > >...