similar to: [RFC] Introducing the maynotprogress IR attribute

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 James, On Fri, Sep 11, 2020 at 2:05 PM James Y Knight <jyknight at google.com> wrote: > > On Fri, Sep 11, 2020 at 12:42 PM Atmn Patel <atmndp at gmail.com> wrote: >> >> Hi Hal, >> >> On Thu, Sep 10, 2020 at 8:54 PM Hal Finkel <hfinkel at anl.gov> wrote: >> > >> > Hi, Atmn, >> > >> > Has anyone else expressed an

Hi Hal, On Thu, Sep 10, 2020 at 8:54 PM Hal Finkel <hfinkel at anl.gov> wrote: > > Hi, Atmn, > > Has anyone else expressed an opinion regarding the naming? We need to > clarify the semantics in C, it seems. No other names have come in yet, in total the names proposed so far (I think) are: - maynotprogress - maybenoprogress - might_not_progress - nfpg - no_fpg and the loop

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

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

Hi Nicolai and Hal, I was wondering if your present concerns regarding the directions of the proposed attributes and semantics of the current direction had been addressed, so I thought I'd send over a friendly ping. Have they? Atmn On Wed, Sep 9, 2020 at 1:08 AM Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > > On 9/8/20 9:08 PM, Hal Finkel wrote: > >

On 9/7/20 4:48 PM, Nicolai Hähnle wrote: > Hi Johannes, > > > On Mon, Sep 7, 2020 at 11:17 PM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> >> > As a separate comment, I don't find the reference to the C++ spec in >> >> > https://reviews.llvm.org/D86233 to be informative enough. Whenever >> >> > that

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

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

Most of my programs contain loops that the LoopDeletion pass is unable to remove. It appears that the following code in LoopDeletion.cpp:152 is the culprit: ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); const SCEV *S = SE.getMaxBackedgeTakenCount(L); if (isa<SCEVCouldNotCompute>(S)) return Changed; So, LoopDeletion thinks my loops might be infinite so it

Andrew Clinton wrote: > Most of my programs contain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(S)) > return

On 11/24/2010 06:55 PM, Owen Anderson wrote: > On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: > > >> Most of my programs contain loops that the LoopDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >>

Hello All, I filed a bug https://bugs.llvm.org/show_bug.cgi?id=35884 which I want to fix but I'm in trouble with detecting who is wrong :) The story is as follows: LoopDeletion tries to delete an invariant loop which has a def with use in some unreachable block. The IR is well-formed due to any use in unreachable block is dominated as Verifier states. LoopDeletion detected the loop as

On 11/25/2010 12:59 PM, Andrew Clinton wrote: > On 11/24/2010 06:55 PM, Owen Anderson wrote: >> On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: >> >> >>> Most of my programs contain loops that the LoopDeletion pass is unable >>> to remove. It appears that the following code in LoopDeletion.cpp:152 >>> is the culprit: >>> >>>

On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: > Most of my programs contain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if

On 11/24/2010 03:36 PM, Nick Lewycky wrote: > Andrew Clinton wrote: >> Most of my programs contain loops that the LoopDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >> const SCEV *S =

Hi, the newly added LoopDeletion pass uses loop-deletion as it's name (and thus commandline option for opt). Looking at the other loop passes (loop-rotate, loop-unroll, loop-reduce), perhaps loop-delete would be a better name? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: