[LLVMdev] LLVM introduces racy read - Unsafe transformation?

[David Chisnall]

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.

There was a related discussion about a year ago regarding this exact transformation because, although it is not necessarily invalid, it is not necessarily a good idea.  Reading the value of a will generate cache coherency traffic and the extra cache-line ping-pong may be slower than a conditional branch.

David