On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote:> At least in C/C++ that's UB, yes.So you cannot map every turing machine to a valid C/C++ program then. :) Also, does this mean that "daemon" programs that run continuously till they're killed by the OS (using a mechanism that is not visible in C) are effectively undefined? -- Sanjoy> Some years ago there was a lot of discussion about this on the ML. Se > Nick's patch, for example: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103670.html > The patch was eventually dropped, I don't recall why. I think it's fine to > assume that readnone functions always terminate. It would probably fine for > readonly functions as well. > > Nuno > > > -----Original Message----- > From: Sanjoy Das > Sent: Saturday, June 27, 2015 9:29 PM > Subject: [LLVMdev] readonly and infinite loops > > Running -early-cse on > > declare void @rn() readnone nounwind > > define void @f() { > entry: > call void @rn() > ret void > } > > removes the call to @rn(). But @rn() could have had an infinite loop > in it in which case @f() went from being a non-terminating > program to an terminating no-op. Is this intentional? > > The only way I can see this transform being legal is if infinite loops > are declared to have undefined behavior, but I could not find anything > in the LLVM specification that mentions this. > > -- Sanjoy
In C, dunno, but in LLVM, it means they aren't readonly :) On Sat, Jun 27, 2015 at 2:31 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:> On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> At least in C/C++ that's UB, yes. > > So you cannot map every turing machine to a valid C/C++ program then. :) > > Also, does this mean that "daemon" programs that run continuously till > they're killed by the OS (using a mechanism that is not visible in C) > are effectively undefined? > > -- Sanjoy > >> Some years ago there was a lot of discussion about this on the ML. Se >> Nick's patch, for example: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103670.html >> The patch was eventually dropped, I don't recall why. I think it's fine to >> assume that readnone functions always terminate. It would probably fine for >> readonly functions as well. >> >> Nuno >> >> >> -----Original Message----- >> From: Sanjoy Das >> Sent: Saturday, June 27, 2015 9:29 PM >> Subject: [LLVMdev] readonly and infinite loops >> >> Running -early-cse on >> >> declare void @rn() readnone nounwind >> >> define void @f() { >> entry: >> call void @rn() >> ret void >> } >> >> removes the call to @rn(). But @rn() could have had an infinite loop >> in it in which case @f() went from being a non-terminating >> program to an terminating no-op. Is this intentional? >> >> The only way I can see this transform being legal is if infinite loops >> are declared to have undefined behavior, but I could not find anything >> in the LLVM specification that mentions this. >> >> -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
No; the standard says that we get to assume that the loop will eventually terminate, or do I/O, or a few other possible things. I can find the text for you later if you'd like. -Hal Sent from my Verizon Wireless 4G LTE DROID Sanjoy Das <sanjoy at playingwithpointers.com> wrote: On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote:> At least in C/C++ that's UB, yes.So you cannot map every turing machine to a valid C/C++ program then. :) Also, does this mean that "daemon" programs that run continuously till they're killed by the OS (using a mechanism that is not visible in C) are effectively undefined? -- Sanjoy> Some years ago there was a lot of discussion about this on the ML. Se > Nick's patch, for example: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103670.html > The patch was eventually dropped, I don't recall why. I think it's fine to > assume that readnone functions always terminate. It would probably fine for > readonly functions as well. > > Nuno > > > -----Original Message----- > From: Sanjoy Das > Sent: Saturday, June 27, 2015 9:29 PM > Subject: [LLVMdev] readonly and infinite loops > > Running -early-cse on > > declare void @rn() readnone nounwind > > define void @f() { > entry: > call void @rn() > ret void > } > > removes the call to @rn(). But @rn() could have had an infinite loop > in it in which case @f() went from being a non-terminating > program to an terminating no-op. Is this intentional? > > The only way I can see this transform being legal is if infinite loops > are declared to have undefined behavior, but I could not find anything > in the LLVM specification that mentions this. > > -- Sanjoy_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150627/fd06cade/attachment.html>
On Sat, Jun 27, 2015 at 3:36 PM, Finkel, Hal J. <hfinkel at anl.gov> wrote:> No; the standard says that we get to assume that the loop will eventually > terminate, or do I/O, or a few other possible things. I can find the text > for you later if you'd like.Actually, I'm more interested in what LLVM (not C/C++) says about "while(1);" loops. Such loops are legal in Java (and possibly other languages that use LLVM) so it's problematic if LLVM specifies them to have UB. -- Sanjoy> > -Hal > > Sent from my Verizon Wireless 4G LTE DROID > > > Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> At least in C/C++ that's UB, yes. > > So you cannot map every turing machine to a valid C/C++ program then. :) > > Also, does this mean that "daemon" programs that run continuously till > they're killed by the OS (using a mechanism that is not visible in C) > are effectively undefined? > > -- Sanjoy > >> Some years ago there was a lot of discussion about this on the ML. Se >> Nick's patch, for example: >> >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103670.html >> The patch was eventually dropped, I don't recall why. I think it's fine >> to >> assume that readnone functions always terminate. It would probably fine >> for >> readonly functions as well. >> >> Nuno >> >> >> -----Original Message----- >> From: Sanjoy Das >> Sent: Saturday, June 27, 2015 9:29 PM >> Subject: [LLVMdev] readonly and infinite loops >> >> Running -early-cse on >> >> declare void @rn() readnone nounwind >> >> define void @f() { >> entry: >> call void @rn() >> ret void >> } >> >> removes the call to @rn(). But @rn() could have had an infinite loop >> in it in which case @f() went from being a non-terminating >> program to an terminating no-op. Is this intentional? >> >> The only way I can see this transform being legal is if infinite loops >> are declared to have undefined behavior, but I could not find anything >> in the LLVM specification that mentions this. >> >> -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Sat, Jun 27, 2015 at 2:46 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> In C, dunno, but in LLVM, it means they aren't readonly :)In that case, -functionattrs needs to be fixed: define void @infloop() { entry: br label %l l: br label %l } == opt -functionattrs ==> ; Function Attrs: readnone define void @infloop() #0 { entry: br label %l l: ; preds = %l, %entry br label %l } attributes #0 = { readnone } -- Sanjoy