[LLVMdev] Reviving the new LLVM concurrency model

[Eli Friedman]

On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> 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 intent of the model is that if the behavior of a program doesn't
depend on the value of a load, it's okay if it is undef.  This allows,
for example, hoisting loads which are conditionally executed out of
loops.

> 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.

"can introduce undefined behavior", I meant "Specifically, in the case
where another thread might write to and read from an address,
introducing a store can change a load that may see exactly one write
into a load that may see multiple writes."  Any suggestion for how to
phrase that paragraph more clearly?

-Eli