similar to: [LLVMdev] Induction Variables vs Loop Control Variable

Hi, Well, yes i did try your suggestion but i keep on running into a compilation problem. The error is: llvm[0]: Compiling Hello.cpp for Release build (PIC) /home/saraswat/llvm/llvm-2.1/include/llvm/ADT/GraphTraits.h: In instantiation of `llvm::GraphTraits<llvm::ilist_iterator<llvm::BasicBlock> >': Hello.cpp:59: instantiated from here

Hi Pabhat, Have you checked out DepthFirstIterator? (include/llvm/ADT/ DepthFirstIterator.h). It provides an iterator abstraction to perform a forward/reverse DFS traversal of a graph. Many of the LLVM datatypes that represent graphs have a template specialization of the GraphTraits<> class which allows separate algorithms to treat them as graphs, walk them, etc. (Both BasicBlock

I've noticed that there was an attempt to mitigate ExitValues problem in https://reviews.llvm.org/D12494 that went nowhere. Were there particular issues with that approach? -- Danila From: Philip Reames [mailto:listmail at philipreames.com] Sent: Saturday, August 10, 2019 02:05 To: Danila Malyutin <Danila.Malyutin at synopsys.com>; Finkel, Hal J. <hfinkel at anl.gov> Cc: llvm-dev

Hi all, Is there a way to walk through ALL the predecessors of a basic block in a CFG. I tried to iterate over the preds using this method for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++I) { BasicBlock *PredBB = *PI; } but this only gives the immediate predecessors for a basic block. For example, in this sample control flow graph. entry -> bb1 -> bb2 -> bb4

Thanks. I've rebased this patch on top of the recent LLVM (it was straightforward) and applied it in my fork. It seems to have solved one of the problems I was having. Would LLVM be interested if I submit the updated version for the review? -- Danila From: Philip Reames [mailto:listmail at philipreames.com] Sent: Tuesday, August 13, 2019 19:01 To: Danila Malyutin <Danila.Malyutin at

Hi Hal, I see. So LSR could theoretically counteract undesirable Ind Var transformations but it's not implemented at the moment? I think I've managed to come up with a small reproducer that can also exhibit similar problem on x86, here it is: https://godbolt.org/z/_wxzut As you can see, when rewriteLoopExitValues is not disabled Clang generates worse code due to additional spills,

Hi aditya, There are two ways to cound the number of predecessors for each basic block. You can generate the control flow graph using the CallGraphScc pass with the granularity of basic block and can simply traverse the graph bottom up till the root. The number of nodes encountered would be the number of predecessors. The second way would be to use the special ;preds marker in the llvm IR. Each

I just subscribed this group. This is my first time to post a question (not sure if this is a right place for discussion) after I have a brief look at LLVM OPT (dev trunk). I would expect loop simplification and induction variable canonicalization pass (IndVarSimplify pass) should be able to convert the following loops into a simple canonical form, i.e., there is a canonical induction variable

Some of the LoopInfo APIs are preceeded by this comment: // Note that all of these methods can fail on general loops (ie, there may not // be a preheader, etc). For best success, the loop simplification and // induction variable canonicalization pass should be used to normalize loops // for easy analysis. These methods assume canonical loops. What Pass would that be? IndVarSimplify?

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced

Hi, How does LLVM identify induction variables of a loop? Is the algorithm based on SSA graphs? I have a complicated loop and I need to do some analysis around it. Can anyone please point me to source of identification part? -- *Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this mail are of my own and my employer has no take in it. * Thank You. Madhur D. Amilkanthwar

Dear all, I was looking for to compile some benchmarks and generate code using different register allocation algorithms. As i can see, the built in options for register allocation in llvm are 1. Simple 2. Local 3. Linear Scan I want to compare the generating code also with a graph coloring based register allocation approach. Is this also built in by default by llvm. Are there some other

But even for a very simple loop: int test1 (int *x, int *y, int *z, int k) { int sum = 0; for (int i = 10; i < k; i++) { z[i] = x[i] / y[i]; } return sum; } The initial value of induction variable is not zero after compiling with -O3 -mcpu=power8 x.cpp -S -c -emit-llvm -fno-unroll-loops (see bottom of the email for IR) Also I can write somewhat more complicated loop where step

Hello LLVM, Can you suggest a good way to use the loops and induction variable passes to map loop exiting BasicBlocks to InductionVariables. That is, can we use these tools to identify the loop condition. What i have tried Function Pass: foreach BB if(terminal is loop exit of containing loop) trace back to instruction producing the cond that the branch branches on -

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

Hi, If we add multiple loop passes to the pass manager in PassManagerBuilder.cpp consecutively without any func/module pass in between, I used to think they would belong to the same loop pass manager. But it does not seem to be the case. For example for this code snippet PM.add(createIndVarSimplifyPass()); // Canonicalize indvars MPM.add(createLoopIdiomPass()); //

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;

On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote: > On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote: > > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > > > Hi, > > > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test

Hi all... I am developing a program slicing framework using LLVM. The idea is to remove the computation parts from the program and only keep the parts relevant for the control flow. For example, in the following C loop. for (i=0;i<=VAL;) { printf("In the loop"); a=b+c; b=h+k; i++; printf("%d",i); } after slicing... for (i=0;i<=VAL;) { i++;