similar to: CFG manipulation and !llvm.loop metadata

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 =

So I have a loop with two blocks, a header (which points to return and latch) and a latch (which points to return and header). I have inserted a few new blocks, called H and F. Header now points to H and latch. Latch now points to F. H points to F. F points to Header and return. The PHI Nodes have been updated in Header accordingly, now coming from the preheader and F (instead of latch). My

I've been playing with approaches to getting better optimization of loops which contain infrequently executed slow paths. I've gotten as far as throwing together a proof of concept implementation of a profile guided optimization to separate a single loop with multiple latches into a loop nest, but I want to get feedback from interested parties before investing much more effort. The

I'm getting some odd behavior out of MBP and was hoping someone knowledge of the code might be able to give some guidance. Fair warning, I'm trying to describe a problem in code I don't really understand, so if something doesn't make sense, assume I misunderstood something. The problematic case I'm seeing is that cold blocks are being placed between the preheader and

So essentially I'm adding a path inside of the loop. Is there a way to have llvm automatically create new IR and update the PHIs simply by adding a block like this and changing the DomTree? ---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Feb 2, 2012 at 12:08 PM Subject: Updating PHI for Instruction Domination? To: llvmdev at cs.uiuc.edu So

Not that I'm aware of. -eric On Feb 2, 2012, at 3:47 PM, Ryan Taylor wrote: > So essentially I'm adding a path inside of the loop. Is there a way to have llvm automatically create new IR and update the PHIs simply by adding a block like this and changing the DomTree? > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date:

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:06:03 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Wednesday, July 15, 2015 7:34:54 PM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung

In https://bugs.llvm.org/show_bug.cgi?id=38011 (see also https://reviews.llvm.org/D48721) a problem was revealed related to llvm.loop metadata. The fault was that clang added the !llvm.loop metadata to branches outside of the loop (not only the loop latch). That was not handled properly by some opt passes (simplifying cfg) since it ended up merging branch instructions with different !llvm.loop

On Feb 7, 2013, at 10:53 AM, Michele Scandale <michele.scandale at gmail.com> wrote: >> Thanks for the details. Please add them to a bug report. > > I will do this. Thanks. >> InstCombine is certainly interfering with our ability to analyze the loop. I think the problem is that ScalarEvolution cannot reason about signed division. This is a general problem independent of

On 7/30/2013 11:44 PM, Chris Lattner wrote: > > The canonical form should be that loop invariants are hoisted. The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common" properties of a loop, such as header, preheader, latch branch, etc. > Optimizations should not depend on perfect

On Hexagon, unguarded loops cannot be converted to hardware loops. If the loop's latch branch alone handles the iteration count, including the possibility of 0, then the loop cannot be converted to a hardware loop, because hardware loops must iterate at least once. If the entire loop is guarded against zero iteration count, we can put the loop setup in the preheader, since at that point the

On 2/25/2013 2:08 PM, Redmond, Paul wrote: > > I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Latch is a branch to the header. What branch in particular do you have in mind? Loop

Hi all, I would like to propose an improvement of the “almost dead” block elimination in Transforms/Local.cpp so that it will preserve the canonical loop form for loops with a volatile iteration variable. *** Problem statement Nested loops in LCALS Subset B (https://codesign.llnl.gov/LCALS.php) are not vectorized with LLVM -O3 because the LLVM loop vectorizer fails the test whether the loop

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Chandler Carruth" <chandlerc at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:58:02 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > ----- Original Message ----- > >

> Thanks for the details. Please add them to a bug report. I will do this. > InstCombine is certainly interfering with our ability to analyze the loop. I think the problem is that ScalarEvolution cannot reason about signed division. This is a general problem independent of your target. At the moment I'm not sure if we can teach ScalarEvolution to reason about this, or if we can defer

Hi All, I have got one domination error after running LoopVectorizer with VPlanNatviePath. Let's see simple IR snippet after loop vectorization with VPlanNatviePath. vector.body: ... br label %for.body10.preheader67 for.body10.preheader67: ; preds = %for.cond.cleanup972, %vector.body %vec.phi = phi <4 x i64> [ zeroinitializer, %for.cond.cleanup972 ], [ %8,

Hi, I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Note that I'm asking about llvm.loop.parallel not llvm.mem.parallel_loop_access which obviously must be inside the loop. It seems

Hi Gerolf, I think we have several (perhaps separable) issues here: 1. Do we have a canonical form for loops, preserved through the optimizer, that allows naturally-constructed loop nests to remain separable? 2. Do we forbid non-lowering transformations that turn vectorizable loops into non-vectorizable loops? 3. How do we detect cases where transformations cause a negative answer to either

On 02/08/2013 06:56 AM, Andrew Trick wrote: > There's been talk of adding metata do the branch that terminates the loop latch block. What llvm calls the "latch" is just a unique backward branch to the loop header and not necessarilly even a loop exit. > > I'm not sure how you would interpret that metadata, since the branch exit may be rewritten (just like the loop