[LLVMdev] LLVM Concurrency and Undef (original) (raw)

Eli Friedman eli.friedman at gmail.com
Sat Sep 10 19:35:53 PDT 2011

On Sat, Sep 10, 2011 at 7:13 PM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote:

On Aug 22, 2011, at 5:29 PM, Eli Friedman wrote: LLVM Atomics and Concurrency guide also states the following "Note that speculative loads are allowed; a load which is part of a race returns undef, but does not have undefined behavior" If the speculative loads returns an undef and the returned value is used, then it results in an undefined behavior. Am I correct? It behaves like any other undef value... which do often lead to undefined behavior. Eli,  Java by necessity has to be well defined in spite of data-races (because, IIUC, detecting data-races in just about anything and java-byte-codes in particular is an N-P-complete problem, so cannot be part of the byte-code validation process, therefore any byte-code which does have a data-race and does pass validation must still execute with defined behavior).

Yes.

so, again IIUC, it appears that LLVM-IR could not be used for Java if we import C/C++'s strict "data-race implies undefined" semantics into our IR.

You can't use regular load and store instructions, but I have recently added load and store instructions with the appropriate semantics for Java to the LLVM IR. See http://llvm.org/docs/Atomics.html#o_unordered .

-Eli

More information about the llvm-dev mailing list