similar to: [LLVMdev] Debug metadata after simplifications

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

Hi all, It looks like the induction variable simplification pass prefers doing a zero-extension to compute the wider trip count of loops when extending the IV. This can sometimes result in loss of information making ScalarEvolution's analysis conservative which can lead to missed performance opportunities. For example, consider this loopnest- int i, j; for(i=0; i< 40; i++) for(j=0;

Is that why we do not deduce +<nsw> from "add nsw" either? Is that an intrinsic limitation of creating a context-invariant expressions from a Value* or is that a limitation of our implementation (our unification not considering the nsw flags)? On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 12:21 PM, Alexandre Isoard via

Hi, I have this small test case- %struct1 = type { i32, i32 } @glob_const = internal constant [4 x %struct1] [%struct1 { i32 4, i32 5 }, %struct1 { i32 8, i32 9 }, %struct1 { i32 16, i32 0 }, %struct1 { i32 32, i32 10 }], align 16 define void @foo() { entry: br label %loop loop: ; preds = %loop, %entry %iv = phi %struct1* [ getelementptr

Hi Sanjoy, I have attached the IR I got by compiling with -O2. This is just before we widen the IV. To get the backedge taken count info I ran indvars on it and then replaced zext with sext. I think regardless of where we decide to add this transformation in the pipeline, it should try to preserve as much information as it can. This means that we should generate sext for signed IVs and

Thanks for the suggestion but datalayout info did not solve the problem! -Pankaj -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Tuesday, August 20, 2019 5:26 PM To: Chawla, Pankaj <pankaj.chawla at intel.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] missing simplification in ScalarEvolution? Try adding a datalayout with pointer size

Hi Sanjoy, Thanks for the reply! Your approach sounds good to me! I think 1) is legal as address wraparound in unsigned range doesn't make sense given a positive offset, but I am not sure. I think umax will not be added if we can prove the predicate as known. I am not sure whether umax will get simplified if we add nuw to the expressions. -Pankaj -----Original Message----- From: Sanjoy

Hello, I am trying to use scalar evolution pass using following command; opt -analyze -mem2reg -indvars -loop-simplify -scalar-evolution < vec.bc when vec.bc is generated using newer version of LLVM i.e LLVM 6 and 7 i get following message in the end; Determining loop execution counts for: @main Loop %8: Unpredictable backedge-taken count. Loop %8: Unpredictable max backedge-taken count. Loop

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

Thank You.. I used following command to generate .bc or .ll /Documents/clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang -O0 -emit-llvm -S -o vec4.ll vecsum.c /Documents/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/clang -O0 -emit-llvm -S -o vec7.ll vecsum.c On Wed, Jan 16, 2019 at 6:49 AM Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > It is hard to tell

Hello, If I run clang on the following code: void func(unsigned n) { > for (unsigned long x = 1; x < n; ++x) > dummy(x); > } I get the following llvm ir: define void @func(i32 %n) { > entry: > %conv = zext i32 %n to i64 > %cmp5 = icmp ugt i32 %n, 1 > br i1 %cmp5, label %for.body, label %for.cond.cleanup > for.cond.cleanup:

Hi: I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. 1. MachineDominatorTree *domintree = new MachineDominatorTree(); domintree->runOnMachineFunction(mf); 2. Then travel mf one by one. When domintree->dominates(next,current) is true, there is a backedge from current node to next node. move this backedge form CFG. But I find A LOOP in

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

Hi, Dear Boissinot: 1. When I have irreducible CFG, I travel its nodes by DFS. search backedge for every node. After I finish one node, push it into a stack. [0, 1, 2, M] <---push. [0, 1, 2, M,...N] <---push. When resolving node M, find a edge from node N to node M, N is not in stack(M < N), It is a backedge. N is in stack(M > N), It is NOT a backedge.

2010/1/25 任坤 <hbrenkun at yahoo.cn>: > Hi: > > I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. > > 1. MachineDominatorTree *domintree = new MachineDominatorTree(); > domintree->runOnMachineFunction(mf); > > 2. Then travel mf one by one. > When domintree->dominates(next,current) is true, there is a backedge

Hi, Is it fair to say that we require loops to be in canonical form with a single backedge to which we attach llvm.loop.parallel? Or is it the frontend's responsibility to attach the metadata to each backedge? Looking at the patch there is an assumption that there is a single loop latch. Clang, for example, generates loops with multiple backedges (e.g, while with continue.) How does pocl

Hi, On 02/15/2013 06:37 PM, Redmond, Paul wrote: > Is it fair to say that we require loops to be in canonical form with a > single backedge to which we attach llvm.loop.parallel? Or is it the > frontend's responsibility to attach the metadata to each backedge? I have assumed so far only a single backedge. I think we have to annotate all the backedges in Clang where the parallel

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

Hi:    I want to do some optimization on MachineLoop. So I want to get MachineLoopInfo from MachineFunction. I reference MachineLICM.cpp. So I try to write a pass in Target/mytarget directory. I find there is Error. llvm/include/llvm/PassAnalysisSupport.h:198: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::MachineLoopInfo]: Assertion