search for: memorybarrier

...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 reasonable names. :-/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------...

...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/itgoestoeleven/archive/2008/03/11/the-joys-of-compiler-and-processor-reordering-why-you...

...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. Wait, it defines MemoryFence() AND MemoryBarrier()?? Sheesh, they had to take all the reasonable names. :-/ --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/200...

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 reasonable names.  :-/

...11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. Are they macros or functions? If macros, why not just #undef them at the top of Atomics.h? -Chris > > > 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 reasonable names. :-/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

In the current trunk, System/Atomic.[h,cpp] define 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.

...ern/OSAtomic.h> +#endif int main() { #ifdef _MSC_VER volatile LONG val = 1; @@ -13,6 +16,12 @@ InterlockedCompareExchange(&val, 0, 1); InterlockedIncrement(&val); InterlockedDecrement(&val); +#elif defined(__APPLE__) + int32_t val = 1; + OSMemoryBarrier(); + OSAtomicCompareAndSwap32(0, 1, &val); + OSAtomicIncrement32(&val); + OSAtomicDecrement32(&val); #else volatile unsigned long val = 1; __sync_synchronize(); Index: include/llvm/Support/Atomic.h =================================================...

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

...lane: add YUYV support a554090 drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU access ce8f769 drm/nouveau: fix m2mf copy to tiled gart 2e2cfbe drm/nouveau/vm: reduce number of entry-points to vm_map() d0ce7b856 drm/nouveau: make vga_switcheroo code depend on VGA_SWITCHEROO 85b2331 drm: Kill DRM_*MEMORYBARRIER 1d6ac18 drm: Kill DRM_COPY_(TO|FROM)_USER bfd8303 drm: Kill DRM_HZ b072e53 ACPI / nouveau: replace open-coded _DSM code with helper functions 4988d0a nouveau / ACPI: fix memory leak in ACPI _DSM related code 8b48463 ACPI: Clean up inclusions of ACPI header files d8ec26d Linux 3.13 72de182 drm/nouve...