search for: acq_rel

Hi, I have the following test case: define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* noalias nocapture %data0) nounwind { entry: %val1 = load <2 x float>* %data0, align 8 store <2 x float> %val1, <2 x float>* %out, align 8 fence acq_rel %val2 = load <2 x float>* %data0, align 8 store <2 x float> %val2, <2 x float>* %out, align 8 ret void } If I run it though GVN with BasicAliasAnalysis, GVN does not remove the load after the fence. However, if I put the fence instruction in a function, such as: define v...

...lt;ordering>` arguments specify how this +``cmpxchg`` synchronizes with other atomic operations. The both ordering +parameters must be at least ``monotonic``, the ordering constraint on failure +must be no stronger than that on success, and the failure ordering cannot be +either ``release`` or ``acq_rel``. The optional "``singlethread``" argument declares that the ``cmpxchg`` is only atomic with respect to code (usually signal handlers) running in @@ -5032,10 +5035,9 @@ operand is read and compared to '``<cmp>``'; if the read value is the equal, '``<new>``...

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com> wrote: > Is it possible for the debug information to mark all the instructions that arise > from a > language statement as coming from that statement, even though the instructions may > be widely scattered? Yes. > Instructions whose effects > are used in the logic from more than one statement would have to

...vm.org/docs/LangRef.html#ordering> arguments specify how this cmpxchg synchronizes with other atomic operations. Both ordering parameters must be at least monotonic , the ordering constraint on failure must be no stronger than that on success, and the failure ordering cannot be either release or acq_rel ." The way this operation is implemented in the standard library of the Rust programming language, the combination of release (success) and acquire (failure) is not permitted and will fail at runtime, the prevailing opinion being, that a failing CAS with release/acquire ordering is actually...

...owing test case: > > define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* > noalias nocapture %data0) nounwind { > entry: > %val1 = load <2 x float>* %data0, align 8 > store <2 x float> %val1, <2 x float>* %out, align 8 > fence acq_rel > %val2 = load <2 x float>* %data0, align 8 > store <2 x float> %val2, <2 x float>* %out, align 8 > ret void > } > > If I run it though GVN with BasicAliasAnalysis, GVN does not remove the > load after the fence. > According to the LLVM atomics rules...

...o library helper functions calls. These helpers test for the presence of LSE instructions and dispatch to corresponding sequence of instructions. There are 100 helpers resulting from various combinations of instruction = { cas| swp | ldadd | ldset| ldclr| ldeor }, memory model = { relax, acq, rel, acq_rel } and size = {1, 2, 4 , 8, 16}. I am considering two possibilities: i. Atomic Expand pass: add new AtomicExpansionKind::OutOfLine, and if it was set by target expand atomics to RTLIB libcalls. It will require to add 100 new "standardized" library names to RuntimeLibcalls.def and redefi...

...t;> wrote: Hi, I have the following test case: define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* noalias nocapture %data0) nounwind { entry: %val1 = load <2 x float>* %data0, align 8 store <2 x float> %val1, <2 x float>* %out, align 8 fence acq_rel %val2 = load <2 x float>* %data0, align 8 store <2 x float> %val2, <2 x float>* %out, align 8 ret void } If I run it though GVN with BasicAliasAnalysis, GVN does not remove the load after the fence. According to the LLVM atomics rules, the compiler is actually completely f...

...to library helper functions calls. These helpers test for the presence of LSE instructions and dispatch to corresponding sequence of instructions. There are 100 helpers resulting from various combinations of instruction = { cas| swp | ldadd | ldset| ldclr| ldeor }, memory model = { relax, acq, rel, acq_rel } and size = {1, 2, 4 , 8, 16}. I am considering two possibilities: i. Atomic Expand pass: add new AtomicExpansionKind::OutOfLine, and if it was set by target expand atomics to RTLIB libcalls. It will require to add 100 new "standardized" library names to RuntimeLibcalls.def and redefi...

C++ and Java memory models impose restrictions for locks and unlocks, such as a thread that releases a lock must acquired the lock, or the number of locks must be larger than the number of unlocks in the same thread... for enabling some optimizations, for example, simplifying trylocks (http://www.hpl.hp.com/techreports/2008/HPL-2008-56.html), and moving some instructions inside lock acquires

Currently the AtomicExpandPass will lower the following IR: define i1 @foo(i32* %obj, i32 %old, i32 %new) { entry: %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new _*release acquire*_ %v1 = extractvalue { i32, i1 } %v0, 1 ret i1 %v1 } to the equivalent of the following on AArch64: _*ldxr w8, [x0]*_ cmp w8, w1 b.ne .LBB0_3 // BB#1:

On 28 September 2014 22:09, Hal Finkel <hfinkel at anl.gov> wrote: > Thanks Xinmin! > > So we'll need a method to ensure the correct (partial) ordering. I thought that the idea was to avoid computing loop dependencies when safelen is specified, at least at that level. We might do it to a greater length, but we should assume it to be safe for distances < VL. We still need

There was some discussion a while back about adding a C++0x-style memory model and atomics for LLVM a while back (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/31295), but it got stalled. I'm going to try and restart progress on it. Attached are two patches; the first adds a section to LangRef with just the memory model, without directly changing the documentation or implementation