[LLVMdev] Reviving the new LLVM concurrency model

[Jianzhou Zhao]

The current memory model section ends with the following discussions:

"Note that in cases where none of the atomic intrinsics are used, this
model places only one restriction on IR transformations on top of what
is required for single-threaded execution: introducing a store to a
byte which might not otherwise be stored to can introduce undefined
behavior.... "

Why is introducing additional loads allowed? For example, in a program
that already contains two unordered stores to a location l, if we
introduced an unordered load to l, then the load cannot see more than
one stores, it must return undef.

The question is whether the memory model takes the two unordered
stores as a data race that has already makes the program's behavior
undefined. But the spec does not make this point clear.

My second question is whether the "undefined behavior" in "...
introducing a store to a byte which might not otherwise be stored to
can introduce undefined behavior.... " is same to the ``undef'' in the
definition of R_{byte} that can be undef in several cases. Does the
undef mean the LLVM undef values
(http://llvm.org/docs/LangRef.html#undefvalues)? If "undefined
behavior" means a program can do anything, why does R_{byte}  have to
return undef? Thanks.

On Mon, Jul 18, 2011 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> 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 of atomic intrinsics.  This mostly comes from
> https://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest,
> but it's been modified a bit, so please look at the attached version.
> The second fixes the one place I know of where LLVM violates that
> proposed memory model.
>
> I would appreciate any reviews (primarily for the LangRef bits; I'm
> reasonably confident the patch to LICM is correct).
>
> There was some discussion about allowing targets to implement
> unaligned stores by widening, but I've left that out.  No current
> backend uses such an implementation, so there isn't a substantial
> benefit, and allowing it would break some current optimizations (like
> transforming a memset to an unaligned store).  See also the FIXME in
> the LangRef patch about architectures without a proper single-byte
> store instruction.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
Jianzhou