similar to: [LLVMdev] LICM and SCEV AA?

On Oct 31, 2013, at 6:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Hello, > > We currently generate suboptimal code for this loop: > > for (int i = 1; i < LEN; i++) { > a[i] = a[0] + b[i]; > } > > The largest problem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at

Sent from my iPhone > On Nov 2, 2013, at 1:52 AM, Andrew Trick <atrick at apple.com> wrote: > > >> On Oct 31, 2013, at 6:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> Hello, >> >> We currently generate suboptimal code for this loop: >> >> for (int i = 1; i < LEN; i++) { >> a[i] = a[0] + b[i]; >> } >>

----- Original Message ----- > > On Oct 31, 2013, at 6:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > Hello, > > > > We currently generate suboptimal code for this loop: > > > > for (int i = 1; i < LEN; i++) { > > a[i] = a[0] + b[i]; > > } > > > > The largest problem is that we won't vectorize the loop because

On Nov 5, 2013, at 11:42 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 2 November 2013 05:59, Hal Finkel <hfinkel at anl.gov> wrote: > > I would be scared to enable SCEV AA because it's not well tested > > This seems like a solvable problem. SCEV AA itself is something like 30 lines of non-boilerplate code, and essentially does one thing (calls

On 2 November 2013 05:59, Hal Finkel <hfinkel at anl.gov> wrote: > > I would be scared to enable SCEV AA because it's not well tested > > This seems like a solvable problem. SCEV AA itself is something like 30 > lines of non-boilerplate code, and essentially does one thing (calls > getMinusSCEV in both directions and uses getUnsignedRange on the result). > We should

On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote: > > There appear to be two chunks of "functionality" provided by loop passes: > > > > 1) A worklist of loops to process. This is very rarely used: > > 1.1) LoopSimplify and LoopUnswitch add loops to the queue. > > I’m making this up without much thought, but we may benefit

Hi, I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass. I would love to get feedback on the best way to incrementally push in this change. Motivation: There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). We've had test

Hi, Recently I got a crash when I tried to analysis a program with ScalarEvolution AliasAnalysis(SCEV-AA for short). It turns out to be a (possibly) incorrect assertion inside the CompareSCEVComplexity routine. The simplest solution would be just remove that assertion but I also found that the surrounding logics on calculating SCEV cost seems to be incorrect either. Thus I want to discuss with

Hi, Thanks for the input. In my ptr_test.O1.ll, the two loops should fall into the last case due to loop rotations. And I think we should handle that case. I propose to check the dominance relation between loop predecessor blocks of the two loops if there is no dominance relation between their loop headers just like case three. The only thing I'm not pretty sure is that is there guarantee to

On Wed, Jan 22, 2014 at 1:01 AM, Andrew Trick <atrick at apple.com> wrote: > On Jan 22, 2014, at 12:44 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > > On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote: > >> > There appear to be two chunks of "functionality" provided by loop >> passes: >> >

As came up recently in other threads, loop passes really get in the way. Here are some of the ways: - There is only one Loop analysis pass - IVUsers. It seems unlikely that the loop nest walk is critical to computing this or preserving it. - Almost all of the things we think of as "required" and dependencies are actually *transforms* that canonicalize the form of a loop into particular

I'm attempting to add some support for hoisting/sinking of memory-using intrinsics in loops, and so I want to use MemoryDependenceAnalysis in LICM, but when I modify getAnalysisUsge to include this : virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>();

----- Original Message ----- > From: "Ashutosh Nema" <Ashutosh.Nema at amd.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, February 11, 2015 3:20:27 AM > Subject: Re: [LLVMdev] question about licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case

Hi Stefanos, Thanks for your comments. I added both as reviewer. > One question though. Are you sure that this: > This helps with LICM when instructions inside a conditional is loop invariant  > is not achieved with the current LoopRotate pass? Because AFAIK, it does. Basically it inserts > a guard (that branches to the preheader) and then passes like LICM hoist invariant

On 01/07/2015 05:33 PM, Chandler Carruth wrote: > How does this compare with classical approaches of loop peeling, > partitioning, fission, or whatever you might call it? I'm still developing a good sense for this, but let me lay out some observations. Fair warning, this is going to be long and rambling. Let's start with a toy example: while(c) { x = this->x; y =

On Dec 14, 2011, at 7:09 AM, David Gardner wrote: > I'm attempting to add some support for hoisting/sinking of memory-using > intrinsics in loops, and so I want to use MemoryDependenceAnalysis in > LICM, but when I modify getAnalysisUsge to include this : > > virtual void getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesCFG(); >

For doing PRE on the load, it looks like there’s only two things stopping GVN PRE from doing it: * GVN::PerformLoadPRE doesn’t hoist loads that are conditional. Probably this can be overcome with some kind of heuristic that allows it to happen in loops when the blocks where a load would have to be inserted are outside the loop. * IsFullyAvailableInBlock goes around the loop and

One way you could go is to expose the interface in include/llvm/Transforms/Utils/LoopUtils.h. There's a similar approach in the LCSSA and LoopSimplify passes, both define functions used by other passes (e.g LoopUnroll and LICM). On Fri, Dec 19, 2014 at 10:58 PM, Philip Reames <listmail at philipreames.com> wrote: > I've come across similar use cases recently. In particular,

(minor inline additions) On 09/13/2018 01:51 AM, Chandler Carruth wrote: > Haven't had time to dig into this, but wanted to add +Alina Sbirlea > <mailto:asbirlea at google.com> to the thread as she has been working on > promotion and other aspects of LICM for a long time here. Thanks! > On Wed, Sep 12, 2018 at 11:41 PM Philip Reames > <listmail at philipreames.com

I've been looking at compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the