similar to: [LLVMdev] Exit Block Transformation in LoopSimplify

Hi, I have problems to estimate the loop exit count of a simple loop with the ScalarEvolution class. simple loop: ...... int a = 0; for(int i; i < 10; ++i){ a = a + 1; }; ...... For the loop analyzation I use the ScalarEvolution class with the following initialization: ...... void analysis(Function* func) DominatorTree DT = DominatorTree(); DT.recalculate(*func);

Hi, it looks like the IntervalPartition does not work as expected when constructed from another interval partition. Say, I have built an interval partition from function, and the first interval has two basic blocks. When I create second order partition and print all intervals, the second basic block of the function is not seen anywhere. Here's what's going on in IntervalIterator.h:

Hello all, I’m pretty new to LLVM. I'm writing a pass for loop optimization. I clone and rearrange loops, setting the cloned loop as the original loop’s parent. This can be done multiple times, until there is no more work to do. The trouble is, after the first time I do this, the cloned loop's SCEVs become unknown types when they should be AddRecExpr. If I re-run the whole pass on the

Tobias, I am working on one very well hidden issue with Polly loop structure. Here is a brief description. In polly::createLoop() we create something like this (topology is important): polly.start: ; preds = %polly.split_new_and_old ... <some code> br label %polly.loop_header polly.loop_after: ; preds =

I did an update about 1/2 hr ago, and instead of failing to link with -O4, I'm getting an error elsewhere in the compile. I think I need to stop chasing the bleeding edge. pandora 142% svn update At revision 147455. pandora 143% uname -a Darwin pandora.psychiatry.uiowa.edu 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 pandora 144%

Hello. I am trying to create my own LoopVectorize.cpp pass as a separate pass from the LLVM trunk, as described in http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project. Did anybody try something like this? I added close to the end of the .cpp file: /* this line seems to be required - it allows to run this pass as an embedded pass by giving opt -my-loop-vectorize

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

Hello, LoopSimplify try to separate a loop with multiple backedges into a nested loop (an outer loop and an inner loop). Naturally, this kind of a loop corresponds to a single loop in source code. I can see this could be useful for cases described in the comments in lib/Transforms/Utils/LoopSimplify.cpp, which looks like a corner case. For most cases, how does this help ? Junjie

See http://llvm.org/docs/GettingStarted.html#brokengcc and then try building with something OTHER than GCC 4.1.2 . ----- Original Message ---- > From: Nick Johnson <npjohnso at cs.princeton.edu> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Monday, May 11, 2009 3:01:12 PM > Subject: [LLVMdev] Pass Manager hangs with CallGraph and LoopSimplify >

I will try to reduce a test case for the regression I found and will update. Thanks, Balaram From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Friday, June 30, 2017 2:54 PM To: Balaram Makam <bmakam at codeaurora.org>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] LoopSimplify pass prevents loop unrolling On 6/30/2017 11:38 AM, Balaram Makam wrote: Thanks Eli,

Hello, I have discovered a situation in which the pass manager will infinite loop. The minimal test case is below this message. The required structure of these passes is; Before requires CallGraph After requires LoopSimplify and Before I can observe this through opt: opt -load ./libBug.so -after input.bc -o output.bc I built my copy of llvm from svn revision 68820 using gcc 4.1.2 Any

On 05/15/2013 07:08 PM, Sergei Larin wrote: > > Tobias, [..] > > ...or as always I might be missing a big picture here, and I appreciate if > you can explain the original intent. Hi Sergei, thanks for reporting this issue in so much detail. I am afraid there is no bigger story. For some reason the update of the LoopInfo was not included in the original patch of the code

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 I have this program in which fooBuf can only take on NULL or the address of local_fooBuf, and fooBuf and local_fooBuf have scope of the foo function. Therefore there is no way for the fooPtr argument to alias with fooBuf. However, LLVM basicaa and globalsmodref-aa say the 2 pointers may alias. I am thinking whether i should implement a limited form of point-to alias on the fooBuf pointer in

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,

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

I was trying to build the Linux kernel with clang and observed a crash due to incorrect loop optimization: drivers/base/firmware_class.c extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name) { struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw;

Hi All, I’m currently working on a simple task which needs to transform loops into tail-recursive functions. I found the CodeExtractor class a handy helper to use, but later encountered a problem. Consider the following CU struct S { int a, b; }; int foo(struct S *s, unsigned n) {   struct S *next = s;   unsigned i;   for (i = 0; i < n; ++i) {     if (!s[i].a)      

When I increased COLS to the point where the loop could no longer be unrolled, the selection dag code generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed