similar to: Infinite loops with no side effects

Personally, I don't like the side effect intrinsic. It will pollute all the IR generated by non-C frontends. What most of these frontends really want is just a switch to disable a targeted set of optimizations. One thing I like about the function attribute idea is that it's conservatively correct to discard it when doing cross-language inlining. It just becomes something that C-family

On 9/4/20 7:39 PM, Hal Finkel via llvm-dev wrote: > > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> Hi All, >> >> We’ve prepared a new function attribute `maynotprogress` and loop >> metadata `llvm.loop.mustprogress` in order to better formalize the way >> LLVM deals with infinite loops without observable side-effects. This >> is deeply

Hi All, We’ve prepared a new function attribute `maynotprogress` and loop metadata `llvm.loop.mustprogress` in order to better formalize the way LLVM deals with infinite loops without observable side-effects. This is deeply related to the implicit forward progress requirements in the IR. Background: There has been a demonstrated need for clarity within the forward progress requirements in LLVM

I see the usecase for mixed language compilation (that’s probably why you fancy something like the side-effect thing instead right?) BTW if the other proposal passes can we basically assume that if a loop doesn’t have the sideeffect intrinsic in it is then removable? That patch seems to suggest that in its current state llvm is mostly broken for languages that consider all infinite loops as

On 09/29/2017 10:02 PM, Marcello Maggioni via llvm-dev wrote: > I see the usecase for mixed language compilation (that’s probably why you fancy something like the side-effect thing instead right?) It's also about not having parameterized semantics for the IR. I'd certainly find that undesirable. We could make it part of datalayout, or similar, but that has problems with

Hello! I read a bunch of discussions about the matter on this very mailing-list that are relatively recent or relatively old and I couldn’t find much agreement on the matter, so … here again :D LoopDeletion and infinite loops … Currently LoopDeletion bails if non-detectable trip count loops are encountered and that’s fine, there are languages where infinite loops without side effects cannot be

On Fri, Sep 29, 2017 at 7:17 PM, Marcello Maggioni via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello! > > I read a bunch of discussions about the matter on this very mailing-list > that are relatively recent or relatively old and I couldn’t find much > agreement on the matter, so … here again :D > > LoopDeletion and infinite loops … > > Currently

On Fri, Oct 27, 2017 at 1:08 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On 10/27/2017 02:51 PM, Reid Kleckner wrote: > > Personally, I don't like the side effect intrinsic. > > > Understood. I also don't like the fact that it will clutter the IR in many > cases. > > It will pollute all the IR generated by non-C frontends. What most of > these

On Fri, Sep 29, 2017 at 8:02 PM, Marcello Maggioni <mmaggioni at apple.com> wrote: > I see the usecase for mixed language compilation (that’s probably why you fancy something like the side-effect thing instead right?) > That could be a reason, but it wasn't my main motivation. Basically I'm worried about having per-passes specific flags for non-debug purposes. Also, whether

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 9/7/20 2:52 PM, Nicolai Hähnle wrote: > Hi Johannes, > > On Mon, Sep 7, 2020 at 6:51 PM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> On 9/7/20 10:56 AM, Nicolai Hähnle wrote: >>  > Hi Johannes and Atmn, >>  > >>  > On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev >>  > <llvm-dev at

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, July 16, 2015 2:33:21 AM > Subject: Re: [LLVMdev] [RFC] Defining Infinite Loops > > > > > On Thu, Jul 16, 2015 at 12:27 AM Hal Finkel

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, July 16, 2015 1:00:05 AM > Subject: Re: [LLVMdev] [RFC] Defining Infinite Loops > > > FWIW, I'm very much in favor of having a firm and clear answer

On 9/5/20 12:40 AM, Atmn Patel wrote: > On Sat, Sep 5, 2020 at 1:07 AM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> >> On 9/4/20 7:39 PM, Hal Finkel via llvm-dev wrote: >> > >> > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> >> Hi All, >> >> >> >> We’ve prepared a new function attribute

On 9/7/20 10:56 AM, Nicolai Hähnle wrote: > Hi Johannes and Atmn, > > On Sat, Sep 5, 2020 at 7:07 AM Johannes Doerfert via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  > In any case, please explain the intended behavior of the attribute and >>  > the metadata upon inlining. >> >> The attribute will be attached to the caller upon

On 07/17/2015 02:03 AM, Chandler Carruth wrote: > On Thu, Jul 16, 2015 at 11:08 AM Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > ----- Original Message ----- > > From: "Chandler Carruth" <chandlerc at google.com > <mailto:chandlerc at google.com>> > > To: "Hal Finkel" <hfinkel at

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:

Running into problems configuring different locations for the volatile and other database directories. Can someone provide a quick sanity check on what I'm doing below? Thank you. Given [database] volatile database directory = /var/cache/dbdir/volatile persistent database directory = /var/cache/dbdir/persistent state database directory = /var/cache/dbdir/state And given, [root

Hi Bob, [CC: Amitay, who is better at SeLinux] On Wed, 4 Nov 2020 09:33:10 -0500, Robert Buck via samba <samba at lists.samba.org> wrote: > This turns out to be an SELinux issue. Does anyone know the proper commands > to restorecon or otherwise to set the SELinux policy for > persistent/volatile database files moved to a different directory? I'm not sure if you're asking

On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > Sure, if you're willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. > I don't understand what you mean by this. > 1) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con: