search for: atomic_store

Hi Everyone, This might be more a C/C++11 question than a LLVM question: I wondering if it is semantically correct to access an ordinary variable via atomic operations, like: int val; void foo(){ atomic_store((atomic_int *)(&val), 42); } I tried this simple program on clang+llvm and 42 seems to be correctly stored to val. But, is this just by luck or a right way to go? Thanks. - Lei

On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructions. I see, in that case, I don't have any strong opinion. Maybe new instructions would be simpler and cleaner... I quite like the idea of having more expressive atomic operators, as it'll be easier to map high-level...

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

...ag to ~0. Roughly, call_once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== user code callback mutex_lock(mut); atomic_store(&flag, FULLY_INITIALIZED, mo_release); // "release" store, but within a compiled dylib, thus invisible to TSan } mutex_unlock(mut); } If thread A is just after the release store, which is invisible to TSan, __tsan_acquire in thread B will have no effect, and the stores from the...

...it to the instructions, their syntax will be more complex > than they are today, and reading them could prove a challenge. To be clear, Chandler wasn't suggesting any change to the existing load and store instructions. Instead, we were wondering if people like the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe atomic_exchange and atomic_add instructions. > IMHO, we should keep it simple. I agree that multi-task is ubiquitous > nowadays but the detailed implementation might vary considerably from > language to language and making it explicit only helps, at least in &gt...

...Golin wrote: > On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > > To be clear, Chandler wasn't suggesting any change to the existing > > load and store instructions. Instead, we were wondering if people like > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > atomic_exchange and atomic_add instructions. > > I see, in that case, I don't have any strong opinion. Maybe new > instructions would be simpler and cleaner... > > I quite like the idea of having more expressive atomic operators, as > it...

On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com> wrote: > Certainly for languages such as Java, they will make up a surprisingly large > chunk of the loads and stores, and instructions have much mor flexibility in > terms of syntax. On the flip side, it's a lot of plumbing IIRC, and we'd > really need to stick to the very minimal set of operations,

...ug 4, 2012 at 12:11 AM, Lei Zhao <leizhao833 at gmail.com> wrote: > Hi Everyone, > > This might be more a C/C++11 question than a LLVM question: I wondering if it is semantically correct to access an ordinary variable via atomic operations, like: > > int val; > void foo(){ atomic_store((atomic_int *)(&val), 42); } > > I tried this simple program on clang+llvm and 42 seems to be correctly stored to val. But, is this just by luck or a right way to go? Like with nearly all type punning, alias analysis is likely to eat your program if you do this. In LLVM itself, atomic...

...and > exchange operations, but are missing any way to do an atomic > compare-and-swap. This is true for at least ARMv5, SPARCv8, and Intel > 80386. When your minimum CPU is set to such a cpu model, all atomic > operations must be done via libcall -- it's not acceptable for > atomic_store to emit an atomic "store" instruction, but > atomic_fetch_add to require a libcall which gets implemented with a > lock. If that were to happen, then atomic_fetch_add could not actually > be made atomic versus a simultaneous atomic_store. > > > So anyhow, there's...

...s support atomic load, store, and exchange operations, but are missing any way to do an atomic compare-and-swap. This is true for at least ARMv5, SPARCv8, and Intel 80386. When your minimum CPU is set to such a cpu model, all atomic operations must be done via libcall -- it's not acceptable for atomic_store to emit an atomic "store" instruction, but atomic_fetch_add to require a libcall which gets implemented with a lock. If that were to happen, then atomic_fetch_add could not actually be made atomic versus a simultaneous atomic_store. So anyhow, there's basically two paths I think we...

...shard[shardidx][idx]++; > } > > int pthread_create(...) > { > if (updateshardcount()) { > shardlock(); > if (updateshardcount()) { > int newcount = computeshardcount(); > for (int i = oldcount; i < newcount; i++) > shard[i] = malloc(ncounter*sizeof(uint64)); > atomic_store(&shardmask, newcount-1, memory_order_release); > } > shardunlock(); > } > ... > } > > > If we go with this scheme, for tid I would do: __thread threadid; int pthread_create(...) { threadid = goohhash(gettid()); ... } void userfunc() { int tid = threadid+1...

...t; store, and exchange operations, but are missing any way to do an > atomic compare-and-swap. This is true for at least ARMv5, SPARCv8, > and Intel 80386. When your minimum CPU is set to such a cpu model, > all atomic operations must be done via libcall -- it's not > acceptable for atomic_store to emit an atomic "store" instruction, > but atomic_fetch_add to require a libcall which gets implemented > with a lock. If that were to happen, then atomic_fetch_add could not > actually be made atomic versus a simultaneous atomic_store. > > > > > So anyhow, t...

...s.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store_explicit.pass.cpp libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp Expected Passes : 31225 Expected Failures : 211 Unsupported Tests :...

...gt; On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > > > To be clear, Chandler wasn't suggesting any change to the existing > > > load and store instructions. Instead, we were wondering if people like > > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > > > atomic_exchange and atomic_add instructions. > > > > I see, in that case, I don't have any strong opinion. Maybe new > > instructions would be simpler and cleaner... > > > > I quite like the idea of having more expressive a...

...) >>> { >>> if (updateshardcount()) { >>> shardlock(); >>> if (updateshardcount()) { >>> int newcount = computeshardcount(); >>> for (int i = oldcount; i < newcount; i++) >>> shard[i] = malloc(ncounter*sizeof(uint64)); >>> atomic_store(&shardmask, newcount-1, memory_order_release); >>> } >>> shardunlock(); >>> } >>> ... >>> } >>> >>> >>> >> If we go with this scheme, for tid I would do: >> >> __thread threadid; >> >> int pth...

On Apr 17, 2014, at 2:04 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Apr 17, 2014 at 1:27 PM, Justin Bogner <mail at justinbogner.com> wrote: > Chandler Carruth <chandlerc at google.com> writes: > > if (thread-ID != main's thread-ID && shard_count < std::min(MAX, NUMBER_OF_CORES)) { > > shard_count = std::min(MAX,

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for all your work! Hans [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

> On 2 Sep 2016, at 12:11, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Sep 2, 2016 at 12:09 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com>

.../atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp > libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp > libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp > libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store_explicit.pass.cpp > libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp > > Expected Passes : 31225 >...

Hi, I've tagged 3.8.1-rc1, testers can begin testing. -Tom