search for: __sync_synchronize

struct { volatile int flag; int value; } s; int get_value_when_ready() { while (s.flag) ; __sync_synchronize(); return s.value; } This is "valid" legacy code on some processors, yet it's not valid to replace __sync_synchronize with an atomic_thread_fence because, in theory, LLVM could hoist the load of s.value. In practice it currently doesn't, but it may in the future if my understan...

Thanks for the info. My impression is that __sync_synchronize takes no arguments and is the memory barrier, i.e., "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is that right? I would like a little finer control to express just a write barrier (st-st) or a read barrier. -- Mon Ping On Sep 17, 2008, at 5:50 AM, Andrew...

Andrew Haley brought up this interesting issue on the GCC mailing-list that directly affect the stability of the ARM llvm target when using multi-threading. http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00600.html basically using __sync_synchronize() with GCC on ARM does not generate any code for the fence. For what I know: The only working fix for this issue on Linux would be to create a call to a high address Linux kernel helper named __kernel_dmb located at 0xffff0fa0 that performs the memory fence correctly dependent on what kind of ARM...

Hi, I get this error when compiling a code that contains "__sync_synchronize()" fatal error: error in backend: Cannot select: 0x85ddfb0: ch = AtomicFence 0x85fd8d8, 0x85c7890, 0x85dd9e8 [ORD=4] [ID=27]example.c:378:13 0x85c7890: i64 = Constant<7> [ID=5]example.c:378:13 0x85dd9e8: i64 = Constant<1> [ID=6]example.c:378:13 I believe it should be equivale...

On Feb 15, 2008, at 2:29 PM, Andrew Lenharth wrote: > On 2/15/08, Andrew Lenharth <andrewl at lenharth.org> wrote: >> I'll take a hack at the front end support for >> __sync_synchronize after this goes in. > > This is the gcc side of the patch. GCC 4.2 compiles this to a no-op on x86: void foo() { __sync_synchronize(); } Are you seeing different behavior? What am I missing here? -Chris > > > Index: gcc/llvm-convert.cpp > ================================...

Hi Luke, What you say makes sense but I'm not sure it is a good way to go. If we are using a gcc function name __sync_synchronize, I generally feel like we should support it with exactly the same signature and not try to extend it. Otherwise, it might lead to some confusion in the future unless they also plan to extend it the same way. -- Mon Ping On Sep 17, 2008, at 1:14 PM, Luke Dalessandro wrote: > Mon Ping...

Mon Ping Wang wrote: > Thanks for the info. My impression is that __sync_synchronize takes > no arguments and is the memory barrier, i.e., > "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is > that right? That's my understanding as well. > I would like a little finer control to express just a > write barrier (st-st) or a re...

...ctions emitted would change at all on the platforms I'm familiar with. Jeffrey On Wed, Jul 31, 2013 at 4:15 PM, JF Bastien <jfb at google.com> wrote: > struct { > volatile int flag; > int value; > } s; > > int get_value_when_ready() { > while (s.flag) ; > __sync_synchronize(); > return s.value; > } > > This is "valid" legacy code on some processors, yet it's not valid to > replace __sync_synchronize with an atomic_thread_fence because, in > theory, LLVM could hoist the load of s.value. In practice it currently > doesn't, but it...

There is no __sync_synchronize or __sync_val_compare_and_swap on Mac OS X. One might use OSMemoryBarrier or OSAtomicCompareAndSwap32 instead. The patch is attached. - xi -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1248 bytes Desc: not available...

2013/7/31 JF Bastien <jfb at google.com>: > Hi, > > TL;DR: should we add a new memory ordering to fences? > > > ``fence seq_cst`` is currently use to represent two things: > - GCC-style builtin ``__sync_synchronize()`` [0][1]. > - C11/C++11's sequentially-consistent thread fence > ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. > > As far as I understand: > - The former orders all memory and emits an actual fence instruction. > > - The latter only provides a total orde...

Hi, TL;DR: should we add a new memory ordering to fences? ``fence seq_cst`` is currently use to represent two things: - GCC-style builtin ``__sync_synchronize()`` [0][1]. - C11/C++11's sequentially-consistent thread fence ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. As far as I understand: - The former orders all memory and emits an actual fence instruction. - The latter only provides a total order with other sequentially-consiste...

...ink I am using Apple GCC 4.2. i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566) Should I use something else for LLVM? - xi On Sun, May 24, 2009 at 1:20 AM, Owen Anderson <resistor at mac.com> wrote: > > On May 23, 2009, at 9:41 PM, Xi Wang wrote: > > There is no __sync_synchronize or __sync_val_compare_and_swap on Mac > OS X.  One might use OSMemoryBarrier or OSAtomicCompareAndSwap32 > instead.  The patch is attached. > > Actually, __sync_synchronize and __sync_val_compare_and_swap DO exist on > Darwin, but only if you use Apple's GCC 4.2 (or later), just...

...l as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this goes in. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: barrier.patch Type: text/x-diff Size: 6626 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080215/fdd767c0/attachment.patch>

On May 23, 2009, at 9:41 PM, Xi Wang wrote: > There is no __sync_synchronize or __sync_val_compare_and_swap on Mac > OS X. One might use OSMemoryBarrier or OSAtomicCompareAndSwap32 > instead. The patch is attached. Actually, __sync_synchronize and __sync_val_compare_and_swap DO exist on Darwin, but only if you use Apple's GCC 4.2 (or later), just as it is o...

On 2/15/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > I'll take a hack at the front end support for > __sync_synchronize after this goes in. This is the gcc side of the patch. Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 46956) +++ gcc/llvm-convert.cpp (working copy) @@ -4260,6 +4260,15 @@ EmitBlock(new BasicBlo...

...gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566) > > Should I use something else for LLVM? > > - xi > > On Sun, May 24, 2009 at 1:20 AM, Owen Anderson <resistor at mac.com> > wrote: >> >> On May 23, 2009, at 9:41 PM, Xi Wang wrote: >> >> There is no __sync_synchronize or __sync_val_compare_and_swap on Mac >> OS X. One might use OSMemoryBarrier or OSAtomicCompareAndSwap32 >> instead. The patch is attached. >> >> Actually, __sync_synchronize and __sync_val_compare_and_swap DO >> exist on >> Darwin, but only if you use Apple&...

...ruction > that we support. I don't see a gcc name that has the same semantics > as our barrier instruction. For a name, I was thinking of > __builtin_memory_barrier or __builtin_llvm_memory_barrier. Does > anyone object of adding it as built-in or have a better idea for a name? __sync_synchronize is the gcc builtin for a memory barrier. Andrew

...others, and something I misunderstood was pointed out: it is not an explicit goal of LLVM to support or continue supporting legacy code that did what it had to to express functional concurrent code. It may happen to work now, but unless enough LLVM users express interest this may break one day, and __sync_synchronize may not order anything (it may just emit a fence without forcing any ordering). It was pointed out that it's not clear that __sync_synchronize has a clear spec, and that implementing it properly in LLVM may not be tractable or worthwhile. > If you (PNaCl?) explicitly want to define the beha...

...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 =================================================================== --- include/llvm/Support/Atomic.h (revision 151623) +++ include/llvm/Support/Atomic.h (working copy) @@ -22,6 +22,8 @@ #ifdef _MSC_VER typedef long cas_flag; +#elif defined(__APPLE__)...

I would like access to LLVM memory barrier instruction as a built-in from clang, which means that I need a name for it. In gcc, I see names like __builtin_ia32_mfence but those refers to X86 SSE instruction that we support. I don't see a gcc name that has the same semantics as our barrier instruction. For a name, I was thinking of __builtin_memory_barrier or