similar to: [LLVMdev] Improving loop vectorizer support for loops with a volatile iteration variable

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

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

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

The Problem? Nowaday, SCEV called "Scalar Evolution" does only evolate instructions that has predictable operand, Constant-Based operand. such as that can evolute as a constant. otherwise we couldn't evolate it as SCEV node, evolated as SCEVUnknown. important thing that we remember is, we do not use SCEV only for Loop Deletion, which that doesn't really needed on nature loops

Hello, I have a question regarding PGO instrumented BBs (I use IR-level instrumentation). It seems that instrumented BBs do not match between the two compilations for profile-gen and profile-use for some cases. Here is an example from SPECcpu 2006 lbm (a simple case consisting of just two modules). In the first compilation, we have 5 instrumentation points for the main function as follows: $

Here is original C code: void topup(int a[], unsigned long i) { for (; i < 16; i++) { a[i] = 1; } } Here is the IR before the pass where I expect SCEV to return trip-count value ; Function Attrs: nofree norecurse nounwind uwtable writeonly define dso_local void @topup(i32* nocapture %a, i64 %i) local_unnamed_addr #0 { entry: %cmp3 = icmp ult i64 %i, 16 br i1

Hi, I would like some help regarding the LSR pass. It seems that it likes to duplicate address calculations as in the case above, which is highly undesirable on my target. I wonder if there is any way to tell LSR to not duplicate the code in cases like this? Or could I perhaps run CSE after LSR again? What is the logic behind this transformation? It seems that a LSR pass should not insert a

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

On 6/30/2017 7:48 AM, Balaram Makam via llvm-dev wrote: > > Edit. Predecessor -> successor. > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf > Of *Balaram Makam via llvm-dev > *Sent:* Friday, June 30, 2017 10:47 AM > *To:* llvm-dev at lists.llvm.org > *Subject:* [llvm-dev] LoopSimplify pass prevents loop unrolling > > Hi All, > >

Hi All, In the attached test case there, is an unnested loop with 2 iterations. The loop latch block is terminated by an unconditional branch, so simplifycfg folds the almost empty latch block into its predecessor which is the loop header. This results in an additional backedge in the CFG, so when LoopRotate pass is called it canonicalizes the loop into a nested loop. However, now the loop

Hi all, I'm trying to get llvm to optimize away the %cmp to true in define i32 @foo(i32* %array, i32* %length_ptr, i32 %init) { entry: %length = load i32* %length_ptr, !range !0 %len.sub.1 = sub i32 %length, 1 %upper = icmp slt i32 %init, %len.sub.1 br i1 %upper, label %loop, label %exit loop: %civ = phi i32 [ %init, %entry ], [ %civ.inc, %latch ] %civ.inc = add i32 %civ, 1

On Tue, Jan 24, 2017 at 1:20 PM, Sanjay Patel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I started looking at the log files that you attached, and I'm confused. > The code that is supposedly causing the perf regression is created by the > loop vectorizer, right? Except the bad code is not in the "vector.body", so > is there something peculiar about

Hi, I am writing a loop pass to replace the backedge with an edge from latch to exit. Now I just replace the terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: opt: ~/llvm/llvm-trunk/include/llvm/Analysis/LoopInfoImpl.h:297: void llvm::LoopBase<N, M>::verifyLoop() const [with

Hello, I am first time paying with SCEV codebase. I am trying to find out why ScalarEvolution is not able to give correct back edge taken count for an expression. So in my case flow reaches to howFarToZero() and in that function, I have following expressions as SCEV Start = (15 + (-1 * %i) (which is set to Distance SCEV) Step = 1 now, first of all, should I expect Start as ConstantSCEV (15)

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200320/34cdec77/attachment.html> -------------- next part -------------- Hi all, I have encountered some issues with the preservation of the location of llvm.loop metadata (containing optimisation hints), and would appreciate some feedback on the issue. The IR language description states that

On 6/30/2017 11:38 AM, Balaram Makam wrote: > > Thanks Eli, > > I was looking at this code which keeps track of loop headers but is > checking if the destination of branch is a loop header sufficient? > This prevents merging empty preheaders into the loop headers as well. > There isn't really any reason to collapse preheaders anyway; LoopSimplify will recreate them,

Hello . I'm trying to implement FunctionPass for detecting loops in llvm IR. How can I get <condition> for loop from llvm::Loop object.? Is there any example? Thanks in advance, Edvard  -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120723/85e7f2f9/attachment.html>

Hi Nick, I checked in something towards (1) yesterday -- http://reviews.llvm.org/D6748 I was under the impression that (2) is exactly the kind of predicate ScalarEvolution::isKnownPredicate is designed to solve (using isImpliedCondXXX or something like that). Is there a reason to prefer GVN over that? On Wed, Jan 7, 2015 at 10:06 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Sanjoy

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