[LLVMdev] readonly and infinite loops
Sanjoy Das
sanjoy at playingwithpointers.com
Sun Jun 28 01:40:14 PDT 2015
> What's really I missing, I believe, is the equivalent of the GCC "pure" attribute - which explicitly forbids infinite loops. I think readnone + halting (like in the proposed 2010 patch) is good enough, though. Then every function emitted by a C/C++ FE could be marked as halting, and we could then fix bug [2] by requiring "readnone halting".
This looks like the right fix to me too.
> One potential issue with this is that "readnone halting" isn't strong enough to allow speculative execution of functions (because they may have other UB)
Agreed.
> Regarding Java - what are the expected semantics of infinite loops without side-effects, per spec?
> It seems that for "trivial" infinite loops (while(1);) the FE should actually generate a compile-time error, per JLS 14.21:
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.21
By hit and trial with `javac`, it looks like cases like these are legal:
public class P {
public static int f() {
while (true);
}
public static void main(String[] argv) {
f();
}
}
But you're supposed to get compiler errors in cases like this:
public class P {
public static int f() {
while (true);
return 10;
}
public static void main(String[] argv) {
f();
}
}
Since "return 10;" is now an unreachable statement.
In any case, it was misleading of me to talk about Java (the language)
semantics; what I really care about are java *bytecode* semantics,
which is what we JIT compile via LLVM IR. And as far as I can tell,
there is nothing in the bytecode spec that rules out trivial infinite
loops. I will take a closer look and discuss this with my colleagues,
in case I've managed to miss something.
> The JLS does, however, explicitly claim that this is legal code:
> {
> int n = 5;
> while (n > 7) k = 2;
> }
>
> But I don't see what the semantics of this are. Does it actually mandate non-termination?
The execution will never enter the while loop, as far as I can tell.
-- Sanjoy
More information about the llvm-dev
mailing list