search for: loopdelet

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, LoopD...

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

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 invariant due to LCSSA builder did not create a Phi node for this def because this d...

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 removed. If I read the C++ spec right though N4527 (sec 1.10) point 27 says: 27 The implementation ma...

...rcello 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 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 removed. > > If I read the C++ spec right though N4527 (sec 1.10) point 27 says...

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>(); >> const SCEV *S = SE.getMaxBackedgeTakenCount(L); >> if (isa<SCEVCou...

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: >>> >>> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >>> const SCEV *S = SE.getMaxBackedgeTakenCount(L); >&gt...

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 = SE.getMaxBackedgeTakenCount(L); >> if (isa<SCEV...

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 (isa<SCEVCouldNotCompute>(S)) >...

...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 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 removed. >>> >>> If I read the C++ s...

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

...lt;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 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 removed. >> >> If I read the C++ spec right though N4527...

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 >>>> is the culprit: >>>> >>>> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >>>> const SCEV *S = SE.getMaxBackedg...

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

...e passes for which you updated the comments are primarily written by: Chris: lib/Transforms/IPO/StripDeadPrototypes.cpp Devang: lib/Transforms/IPO/StructRetPromotion.cpp Chris: lib/Transforms/Scalar/CodeGenPrepare.cpp Chris/Evan: lib/Transforms/Scalar/JumpThreading.cpp Chris: lib/Transforms/Scalar/LoopDeletion.cpp Who should probably review the added comments for accuracy. — Gordon

...le conservative implementation would be as a "contains no loops" analysis. Obviously fancier implementations are possible, but we'd like to avoid having the FunctionAttrs depend on LoopInfo or SCEV which would be needed for loop finiteness analysis. Additionally, we already have the LoopDeletion pass interleaved, which should handle exactly those cases anyways. Thoughts? --Owen

...cate that this function is exempt from the above requirement. This will allow frontends to disable IR optimizations that would otherwise optimize away their infinite loops without side-effects. - Implement `llvm.loop.mustprogress` as a loop metadata to notify to the LLVM optimization passes such as LoopDeletion that even if this function is permitted to not make progress, this loop is still required to make progress because it is not one of the infinite side-effect free loops permitted by the frontend language specs. Note that loop metadata can be dropped, so even if this metadata is dropped, we would...

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 standard pass set, because remo...

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? No opinions on this? If this is ever going to be changed, it's probably a good idea...

...deletion. Though, we do remove a call if     the function only contained such a loop, ... Why this way:  - The discussions before concluded IR does have a forward process    guarantee [1,5]. So we don't want to pessimize existing code.    That said, we want to exploit the property, e.g. in LoopDeletion,    during the deduction of `willreturn` (and thereby for    `isGuaranteedToTransferExecutionToSuccessor` and everything that    transitively uses it), ...  - Function attributes are the most fine-grained level, except    instructions, to provide sticky semantics. The instruction level has...