similar to: About LoopDeletion and infinite loops ... again! (RFC?)

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

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

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

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

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

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>(); >>

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

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

On Nov 24, 2010, at 1:23 PM, Andrew Clinton wrote: > > FYI, removing the ScalarEvolution conditional in the LoopDeletion code > (and copying the algorithm to my own loop deletion pass) seems to > correctly handle the elimination of infinite loops. However I'd still > like to find a way to do this with standard passes if possible. There is no way to do this with the

Andrew Clinton wrote: > 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

On Nov 24, 2010, at 3:58 PM, Owen Anderson wrote: > > On Nov 24, 2010, at 1:23 PM, Andrew Clinton wrote: >> >> FYI, removing the ScalarEvolution conditional in the LoopDeletion code >> (and copying the algorithm to my own loop deletion pass) seems to >> correctly handle the elimination of infinite loops. However I'd still >> like to find a way to do

Hello, This email picks up the thread that to my knowledge was last discussed here: http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html In brief, infinite loops containing no side effects produce undefined behavior in C++ (and C in some cases), however in other languages, they have fully defined behavior. LLVM's optimizer currently assumes that infinite loops eventually terminate

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

Hi Chris, >>> FYI, removing the ScalarEvolution conditional in the LoopDeletion code >>> (and copying the algorithm to my own loop deletion pass) seems to >>> correctly handle the elimination of infinite loops. However I'd still >>> like to find a way to do this with standard passes if possible. >> >> There is no way to do this with the

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: