search for: __sync_lock_test_and_set

Is there a "standard" way to check for a lock acquire and release for a transformation pass? Assuming the locks aren't inline asm, so llvm-gcc can compile __sync_lock_test_and_set builtin to llvm.atomic.swap, one could potentially look for IntrinsicInst with the appropriate IntrinsicID. But there's many ways to acquire a lock just using the atomic builtins [1] -- not to mention how a lock implements a blocking acquire. The lock release could use __sync_lock_release, whi...

I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile for a target that I am developing. There is an example: AtomicOps, that uses calls to: __sync_fetch_and_add __sync_val_compare_and_swap __sync_lock_test_and_set These get converted into llvm IR operations like: atomicrmw cmpxchg Is there any way to keep these as function calls, as they are easier to map to the target's eventual functional then having to deal with atomicrmw and cmpxchg -------------- next part -------------- An HTML attachment was sc...

...fig/linux/mutex.h:47: error: incompatible type for argument 1 of '__sync_bool_compare_and_swap' ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h: In function 'gomp_mutex_unlock': ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h:54: error: incompatible type for argument 1 of '__sync_lock_test_and_set' make[4]: *** [alloc.lo] Error 1 I rummaged around in the recent Apple changes but didn't see anything that could cause this. Ciao, Duncan.

...1 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 read barrier. My understanding is that the only types of finer grained control in gcc are the __sync_lock_test_and_set and __sync_lock_release which appear to implement acquire/release style barriers. http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins I expect that there will be large changes once the memory model for C++0X is released, and there may be things implemented in gcc br...

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 Lenharth wrote: > On Tue, Sep 16,

...". 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 read barrier. > > My understanding is that the only types of finer grained control in > gcc > are the __sync_lock_test_and_set and __sync_lock_release which > appear to > implement acquire/release style barriers. > > http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins > > I expect that there will be large changes once the memory model for > C++0X is released, and there ma...

...> incompatible type for argument 1 of '__sync_bool_compare_and_swap' > ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h: In function > 'gomp_mutex_unlock': > ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h:54: error: > incompatible type for argument 1 of '__sync_lock_test_and_set' > make[4]: *** [alloc.lo] Error 1 > > I rummaged around in the recent Apple changes but didn't see anything > that could cause this. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc....

...pe for argument 1 of '__sync_bool_compare_and_swap' > > ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h: In function > > 'gomp_mutex_unlock': > > ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h:54: error: > > incompatible type for argument 1 of '__sync_lock_test_and_set' > > make[4]: *** [alloc.lo] Error 1 > > > > I rummaged around in the recent Apple changes but didn't see anything > > that could cause this. > > > > Ciao, > > > > Duncan. > > _______________________________________________ > > LLV...

..., Dan <westdac at gmail.com> wrote: > > I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile > for a target that I am developing. > > There is an example: AtomicOps, that uses calls to: > > __sync_fetch_and_add > __sync_val_compare_and_swap > __sync_lock_test_and_set > > These get converted into llvm IR operations like: > > atomicrmw > cmpxchg > > Is there any way to keep these as function calls, as they are easier to > map to the target's eventual functional then having to deal with atomicrmw > and cmpxchg > > _____________...

...rgument 1 of '__sync_bool_compare_and_swap' >>> ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h: In function >>> 'gomp_mutex_unlock': >>> ../../../gcc-4.2.llvm/libgomp/config/linux/mutex.h:54: error: >>> incompatible type for argument 1 of '__sync_lock_test_and_set' >>> make[4]: *** [alloc.lo] Error 1 >>> >>> I rummaged around in the recent Apple changes but didn't see >>> anything >>> that could cause this. >>> >>> Ciao, >>> >>> Duncan. >>> ___________________...

> On Jul 21, 2017, at 6:04 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >>> I think your best bet for controlling code bloat is to compile with >>> -fsanitize=undefined -fsanitize-trap=undefined. >> >> Also you may not need all of UBSan's checks at the same time -- so pick >> and choose among its checks using the