similar to: [LLVMdev] how to eliminate dead infinite loops?

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

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 =

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

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

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

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

Hi, On Thu, Sep 28, 2017 at 6:15 PM, Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Actually, I started to copy parts of the ScalarEvolution interface in > order to integrate the analysis passes this way into LLVM > transformations. While it is obviously hard (and probably not useful) to > provide "exactly" the same interface as

Hi Sebastian, thanks for the comments! On 09/27, Sebastian Pop wrote: > On Tue, Sep 26, 2017 at 2:00 AM, Tobias Grosser via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Tue, Sep 26, 2017, at 00:03, Johannes Doerfert wrote: > >> It depends on what you want. If you want a polyhedral scheduler right > >> away, integration is the way to go. > > I

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 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > Dear guys, > > I am having problems to obtain good information from the LoopInfo. > I am always getting a trip count of 0, even though I am clearly passing > a loop with a constant bound. I am using this pass below: Hi, I would propose to first check if the trip count is calculated correctly. I would do this with opt

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

Hi Hal, I add a function named "vectorizeBasicBlock" which allow users to perform basic block vectoirzation inside their pass. But i am not sure whether i missed something as no one use the function right now (But it will be used by Polly sometimes later[1]). In addition, we (tobi and me) also want to make the vectorizer being configured command line flags. To achieve this, we are

On Thu, Aug 12, 2010 at 5:22 PM, Tobias Grosser <grosser at fim.uni-passau.de>wrote: > On 08/12/2010 09:41 PM, Douglas do Couto Teixeira wrote: > >> Dear guys, >> >> I am having problems to obtain good information from the LoopInfo. >> I am always getting a trip count of 0, even though I am clearly passing >> a loop with a constant bound. I am using

Ether, Sounds great! Please keep in mind that, eventually, we'll also want to configure those options from TLI (or something similar). The patch looks good to me. -Hal On Wed, 4 Apr 2012 23:54:18 +0800 Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Hal, > > I add a function named "vectorizeBasicBlock" which allow users to > perform basic block

I'm seeing some very unexpected behavior in a ModulePass I've created. To support both the legacy and new pass managers, I've abstracted away the code to get the passes it depends on: bool MyPass::runOnModule(Module &M) override { auto DominatorGetter = [this] (Function &F) -> DominatorTree & { return