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).
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.
sincerely,
Peter Lawrence.
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