[LLVMdev] LLVM introduces racy read - Unsafe transformation?

David Chisnall
Mon, 26 Jan 2015 17:00:22 -0000

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