search for: memmodel

...ation on the same address concurrently, where at least one of the operations is a write, is a data race, which gives 'undef' results, but as long as you separate your non-atomic operations from other operations with happens-before edges, you'll be fine: http://llvm.org/docs/LangRef.html#memmodel. I don't think Clang exposes any way to get at the raw LLVM operations from C++, which I think is probably the right design. Why do you think you want to access an ordinary variable with atomic operations instead of just defining atomic variables? Jeffrey

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

...is is a very strict consistency model and for > targets with relaxed semantics, LLVM would have to insert > synchronization operations or choose not to vectorize. LLVM already has a memory model. We don't need to add one. ;] It's here for reference: http://llvm.org/docs/LangRef.html#memmodel Also, cache coherency is *not* the right way to think of a memory model. It makes it extremely hard to understand and define what optimization passes are allowed to do. I think LLVM's memory model does a very good job of this for both scalar and vector code today. If you spot problems with it,...

...f="#datalayout">Data Layout</a></li> <li><a href="#pointeraliasing">Pointer Aliasing Rules</a></li> <li><a href="#volatile">Volatile Memory Accesses</a></li> + <li><a href="#memmodel">Memory Model for Concurrent Operations</a></li> </ol> </li> <li><a href="#typesystem">Type System</a> @@ -1470,8 +1471,93 @@ </div> +<!-- ======================================================================= --&...

...safe to hoist it out by promoting it to a scalar in LICM pass? There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have a sample code where GCC is able to promote the memory to scalar and hoist/sink load/store out of loop but LLVM cannot. Is GCC being aggressive here or LLVM missing out an opportunity? Here is my sample code: extern int globalvar; void foo(int n , int incr) { unsigned int i;...

Dan Gohman <dan433584 at gmail.com> writes: > But I don't understand why defining this as not being a data race > would complicate things. I'm assuming the mask values are > statically known. Can you explain a bit more? > > It's an interesting question for autovectorization, for example. > > Thread A: > for (i=0;i<n;++i) > if (i&1)

...to a scalar in LICM pass? >> >> >> There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). >> It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll >> >> However, I have a sample code where GCC is able to promote the memory to scalar and hoist/sink load/store out of loop but LLVM cannot. >> Is GCC being aggressive here or LLVM missing out an opportunity? >> >> Here is my sample code: >> >> extern...

...safe to hoist it out by promoting it to a scalar in LICM pass? There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have a sample code where GCC is able to promote the memory to scalar and hoist/sink load/store out of loop but LLVM cannot. Is GCC being aggressive here or LLVM missing out an opportunity? Here is my sample code: extern int globalvar; void foo(int n , int incr) {   unsigned int i;...

On Mon, Aug 22, 2011 at 7:35 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > 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