[LLVMdev] LLVM introduces racy read - Unsafe transformation?

[Chandler Carruth]

On Mon, Jan 26, 2015 at 9:00 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 26 Jan 2015, at 16:45, sohachak at mpi-sws.org wrote:
> >
> > In the generated IR load(a) is independent of flag value which is not the
> > case in the source program. Hence there is an introduced race between
> > load(a) and store(a) operations when readA() and writeA() runs
> > concurrently.
>
> I believe that this is still not observably racy.  The load is not
> volatile which, in LLVM IR means that it is not allowed to have observable
> side effects.  The address of the load is a constant, so a side-effect-free
> load whose result is not used does not appear to be racy within the
> semantics of LLVM IR - it's just an expensive way of doing a nop.  It
> should materialise an undef value (if someone were to write a formal model
> of LLVM IR with full concurrency semantics), but a select where the unused
> value is undef is still well defined in LLVM IR.
>

FWIW, the C and C++ memory models were design specifically to allow load
speculation, and the LLVM memory model was based heavily on them and
specifically allows load speculation.

As with any speculation, a number of invariants must hold that prove it to
be safe, and there are plenty of circumstances where it isn't profitable,
but the memory model is design to allow it.


Note that race detection tools typically turn these parts of the optimizer
off. You can see this in several places where we disable load speculation
or load widening when running under TSan specifically so that it can
enforce a more conservative model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150126/3f99bbe8/attachment.html>