similar to: [LLVMdev] readonly and infinite loops

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 >

> You dropped some context... > A daemon program wouldn't be readonly. An infinite loop can be. Right. To prevent miscommunication, here is a quick analysis of a problematic (IMO) example: We start with ``` define void @infloop(i1 %c) { entry: br i1 %c, label %l, label %e l: br label %l e: ret void } define void @main_func() { entry: call void @infloop(i1 1) ret

----- Original Message ----- > From: "Nuno Lopes" <nunoplopes at sapo.pt> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com>, nlewycky at google.com > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, June 28, 2015 6:08:52 AM > Subject: Re:

----- Original Message ----- > From: "Nuno Lopes" <nunoplopes at sapo.pt> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Jeremy > Lakeman" <Jeremy.Lakeman at gmail.com>, nlewycky at google.com >

On 30 June 2015 at 14:30, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Interesting. Could you give an example why knowing a function will >>> halt is >>> essential for the heap-to-stack conversion? >>> >> >> The key situation you need to establish in order to do heap-to-stack >> conversion, is that you can see the calls to free (or realloc,

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:

Here's a fun spin on this same topic (I can't file a bug at this moment since llvm.org is down). Consider: define i32 @x(i32* %x, i1* %y) { entry: br label %loop loop: %v = phi i32 [ 0 , %entry ], [ %v.inc, %exit.inner ], [ %v, %loop ] %c = load volatile i1, i1* %y br i1 %c, label %exit.inner, label %loop exit.inner: %c1 = load volatile i1, i1* %y %x.val = load i32, i32*

Hello everyone, The topic of whether or not LLVM allows for infinite loops has come up a lot recently (several times this week already). Regarding motivation, there are two important facts: 1. Some languages, such as Java, have well-defined infinite loops. See: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.9 and:

On 01/04/2017 10:35 PM, Sanjoy Das via llvm-dev wrote: > I just realized that there's an annoying corner case to this scheme -- > I can't DSE stores across readnone maythrow function calls because the > exception handler could read memory. That is, in: > > try { > *a = 10; > call void @readnone_mayunwind_fn(); > *a = 20; > } catch (...) { >

On Wed, Jul 15, 2015 at 11:00 PM, Chandler Carruth <chandlerc at google.com> wrote: > FWIW, I'm very much in favor of having a firm and clear answer to these > questions. > > I also agree that it is an absolute requirement that LLVM have *some* > mechanism for supporting both languages with defined behavior for infinite > loops and a language requirement that all loops

On Tue, Jan 3, 2017 at 10:47 AM, Michael Kuperstein via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Jan 3, 2017 at 9:59 AM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Michael, >> >> On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein >> <michael.kuperstein at gmail.com> wrote: >> > This

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t

Hi Michael, On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein <michael.kuperstein at gmail.com> wrote: > This sounds right to me. > > IIUC, historically, readonly and readnone are meant to model the "pure" and > "const" GCC attributes. These attributes make pretty strong guarantees: > > "[a pure] function can be subject to common subexpression

On 01/05/2017 10:55 AM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> On 01/04/2017 10:35 PM, Sanjoy Das via llvm-dev wrote: >>> I just realized that there's an annoying corner case to this scheme -- >>> I can't DSE stores across readnone maythrow function calls because the >>>

On 01/05/2017 01:20 PM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 11:10 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It is still only a function of its arguments, so it can be CSE'd. > That's a good example -- we can CSE it without worrying about the > memory state flowing in. > > In fact, if we have: > > *a =

Hey Scott, There has been quite a lot of research on capture tracking (aka escape analysis) for Java and other dynamic languages. See e.g.: https://wiki.openjdk.java.net/display/HotSpot/EscapeAnalysis http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html http://dl.acm.org/citation.cfm?doid=320384.320386 Nuno -----Original Message----- From: Scott Egerton via

On 01/05/2017 12:17 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 01/05/2017 10:55 AM, Sanjoy Das wrote: > > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel

For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter

Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to

On 01/05/2017 12:45 PM, Mehdi Amini wrote: > >> On Jan 5, 2017, at 10:39 AM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> On 01/05/2017 12:17 PM, Reid Kleckner wrote: >>> On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev >>> <llvm-dev at lists.llvm.org