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, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> > wrote: >> >> 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 __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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 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 branches or even undocumented in the mainline that give you the kind of control you want. It might make sense to allow __sync_synchronize to be overloaded in the same way that LLVM's builtin is for use in clang, with the default version being the full memory barrier. Luke> > -- Mon Ping > > > On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > >> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> >> wrote: >>> 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 __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 >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 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 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 branches > or even undocumented in the mainline that give you the kind of control > you want. > > It might make sense to allow __sync_synchronize to be overloaded in > the > same way that LLVM's builtin is for use in clang, with the default > version being the full memory barrier. > > Luke > >> >> -- Mon Ping >> >> >> On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: >> >>> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> >>> wrote: >>>> 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 __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 >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev