[LLVMdev] readonly and infinite loops

[Hal Finkel]

----- Original Message -----
> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Sunday, June 28, 2015 3:40:14 AM
> Subject: Re: [LLVMdev] readonly and infinite loops
> 
> > 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.

I agree, we'll need a halting attribute.

> 
> > 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.

In Java, threads can have, formally, a well-defined 'hang' state:

  http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.9

The argument, in part, from Jeremy Manson's memory-model work (which forms the basis for the current specification):

  http://drum.lib.umd.edu/bitstream/1903/1949/1/umi-umd-1898.pdf

for why otherwise-side-effect-free infinite loops in Java need to be well defined, is because a thread's state is observable:

  http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.State.html

For C++, we could actually make a similar argument (we have clocks, threads with join(), etc.), but the committee wisely chose to keep the original prohibition on non-terminating side-effect-free executions regardless.

 -Hal

> 
> > 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory