search for: sequentiallyconsistent

...them is > not atomic, r2==undef. The seq_cst ordering a, c, d, e is consistent > with the observable results. That's true whether printing r2 prints 1, > 2, or 47 since undef can be observed as any value. My confusion is the difference between SC and AcquireRelease. The text says ... SequentiallyConsistent SequentiallyConsistent (seq_cst in IR) provides Acquire semantics for loads and Release semantics for stores. Additionally, it guarantees that a total ordering exists between all SequentiallyConsistent operations. ... Here, what does the total ordering mean? Does it mean given a sequence of SC at...

> } while (__c11_atomic_compare_exchange_weak( > addr, &oldval, newval, memory_order_seq_cst, memory_order_relaxed)); Actually, I think this condition is inverted. Should be "while (!_c11...". Sorry about that. Tim.

...ribes ``fence seq_cst`` in terms of the C11/C++11 primitive, but it looks like LLVM's codebase treats it like the GCC-style builtin. That's strictly correct, but it seems desirable to represent the GCC-style builtin with a ninth LLVM-internal memory ordering that's stricter than ``llvm::SequentiallyConsistent``. ``fence seq_cst`` could then fully utilize C11/C++11's semantics, without breaking the GCC-style builtin. >From C11/C++11's point of view this other memory ordering isn't useful because the primitives offered are sufficient to express valid and performant code, but I believe that...

On Mon, Aug 22, 2011 at 4:20 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>>> On

...n terms > of the C11/C++11 primitive, but it looks like LLVM's codebase treats > it like the GCC-style builtin. That's strictly correct, but it seems > desirable to represent the GCC-style builtin with a ninth > LLVM-internal memory ordering that's stricter than > ``llvm::SequentiallyConsistent``. ``fence seq_cst`` could then fully > utilize C11/C++11's semantics, without breaking the GCC-style builtin. > From C11/C++11's point of view this other memory ordering isn't useful > because the primitives offered are sufficient to express valid and > performant code, but...

....cpp @@ -964,6 +964,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const FunctionDecl *FD, Args[2] = EmitToInt(*this, EmitScalarExpr(E->getArg(2)), T, IntType); Value *Result = Builder.CreateAtomicCmpXchg(Args[0], Args[1], Args[2], + llvm::SequentiallyConsistent, llvm::SequentiallyConsistent); Result = EmitFromInt(*this, Result, T, ValueType); return RValue::get(Result); @@ -990,6 +991,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const FunctionDecl *FD, Value *OldVal = Args[1]; Value *P...

On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte >>> <santosh.nagarakatte at gmail.com>

On 11/19/2014 4:05 AM, Chandler Carruth wrote: > > On Fri, Nov 14, 2014 at 1:09 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > 1. Update the synchronization scope field in atomic instructions > from a > single bit to a wider field, say 32-bit unsigned integer. > > > I

...the C11/C++11 primitive, but it looks like LLVM's codebase treats >> it like the GCC-style builtin. That's strictly correct, but it seems >> desirable to represent the GCC-style builtin with a ninth >> LLVM-internal memory ordering that's stricter than >> ``llvm::SequentiallyConsistent``. ``fence seq_cst`` could then fully >> utilize C11/C++11's semantics, without breaking the GCC-style builtin. >> From C11/C++11's point of view this other memory ordering isn't useful >> because the primitives offered are sufficient to express valid and >> perf...

...imitive, but it looks like LLVM's codebase treats >>> it like the GCC-style builtin. That's strictly correct, but it seems >>> desirable to represent the GCC-style builtin with a ninth >>> LLVM-internal memory ordering that's stricter than >>> ``llvm::SequentiallyConsistent``. ``fence seq_cst`` could then fully >>> utilize C11/C++11's semantics, without breaking the GCC-style builtin. >>> From C11/C++11's point of view this other memory ordering isn't useful >>> because the primitives offered are sufficient to express valid and &...