similar to: [LLVMdev] CFG leaf node

Hello, I have two for loops (one inside the other), that after indvars, looprotate, etc. (the important here is the loop rotate), is similar to this (I've stripped the real operations): define i32 @f() nounwind { entry: br label %bb1 bb1: ; preds = %bb3, %bb1, %entry %i.0.reg2mem.0.ph = phi i32 [ 0, %entry ], [ %i.0.reg2mem.0.ph, %bb1 ], [ %indvar.next9, %bb3 ] ;

Hello, guys. I just tested -reg2mem pass to see how it changes my bitcode. E.g., for the following simple C code: ------------------------------------------------------------- int foo() { int i,j; int sum = 0; for (i=0; i<10; i++) { sum += i; for (j=0; j<3; j++) sum += 2; } return sum; } ------------------------------------------------------------- I could get the

Hello, guys. I just wonder if there is any way to spit out LLVM assembly without any basic block division. E.g., If I emit LLVM assembly for the following simple code: ------------------------------------------------------------ void f_loop(long* c, long sz) { long i; for (i = 0; i < sz; i++) { long offset = i * sz; long* out = c + offset; out[i] = 0; } }

Hello, guys. I am trying to construct higher-level 'for' from the low-level LLVM bitcode(ver 1.9). It's partly successful thanks to David A. Greene's advice suggested to use Control Dependence Graph(CDG). I could find which BB contributes to form which loop with CDG. For example, for this simple function: ----------------------------------------------------------- void bsloop(int

Dear LLVM, Is there any simple way to decide whether there is a control path from one Basic Block to another Basic Block? thanks, Jerry

This is from 'early JIT tests' thread on comp.lang.misc. Given :- int ltst(int x) { int i, j; j=0; for(i=0; i<x; i++)j++; return(j); } This is from the online LLVM compiler. AND It does not seem to optimize it down ! ; ModuleID = '/tmp/webcompile/_24843_0.bc' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple =

Thank you for this comment, Mike. So... your suggestion is to make a valid transform for each loop like: >for (;C;) { > S >} > >is to transform: > >top: >if (!C) goto end; > S >goto top; >end: For now, my code is incomplete so not ready to present for audit yet but I hope it asap. In fact, I couldn't understand what you said: >The cost of the .pdf

On Mon, 21 Feb 2005, Jeff Cohen wrote: > Sorry, I thought I was running selection dag isel but I screwed up when > trying out the really big array. You're right, it does clean it up except > for the multiplication. > > So LoopStrengthReduce is not ready for prime time and doesn't actually get > used? I don't know what the status of it is. You could try it out,

Acutally I mean whether we can start from a node in the graph and follow a path which might be very long, to reach another node. Is there a quick way to do that? thanks, xiaodong On Mon, 11 Nov 2002, Chris Lattner wrote: > > > Is there any simple way to decide whether there is a control path from one > > Basic Block to another Basic Block? > > No efficient way, but you

On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

> Hi Scott, > > Do you mean loop carried dependencies? There is some initial work on > dependence analysis, but it is still pretty young. We also have support for > dependence between memory operations that are not loop aware. > > -Chris I think the dependence analysis will have to be loop aware. For example: bb: %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next,

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I noticed that fourinarow is one of the programs in which LLVM is much slower > than GCC, so I decided to take a look and see why that is so. The program > has many loops that look like this: > > #define ROWS 6 > #define COLS 7 > > void init_board(char b[COLS][ROWS+1]) > { > int i,j; > > for

On Oct 12, 2009, at 5:17 PM, Scott Ricketts wrote: >> Hi Scott, >> >> Do you mean loop carried dependencies? There is some initial work on >> dependence analysis, but it is still pretty young. We also have >> support for >> dependence between memory operations that are not loop aware. >> >> -Chris > > I think the dependence analysis will

Sorry, I thought I was running selection dag isel but I screwed up when trying out the really big array. You're right, it does clean it up except for the multiplication. So LoopStrengthReduce is not ready for prime time and doesn't actually get used? I might consider whipping it into shape. Does it still have to handle getelementptr in its full generality? Chris Lattner wrote:

Hi, Found CloneBasicBlock utility only does the cloning without any remapping. Consider below example: Input block: sw.epilog: ; preds = %sw.bb20, %sw.bb15, %sw.bb10, %sw.bb6, %sw.bb2, %sw.bb, %while.body, %if.end29 %no_final.1 = phi i32 [ %no_final.055, %while.body ], [ 1, %if.end29 ], [ %no_final.055, %sw.bb20 ], [ %no_final.055, %sw.bb15 ], [

On Sat, May 29, 2010 at 1:18 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sat, May 29, 2010 at 12:42 AM, Stéphane Letz <letz at grame.fr> wrote: >> >> Le 29 mai 2010 à 01:08, Bill Wendling a écrit : >> >>> Hi Stéphane, >>> >>> The SSE support is the LLVM backend is fine. What is the code that's generated? Do you have some

> Programmers don't usually write code like this directly, but it is common > for it to happen as a result of the expansion of macros or inline functions. > You would not want to require that a compiler front end *not* produce this. I meant to say that whatever mechanism we use to track dead blocks that may exhibit edge-cases of SSA def-use behavior does *not* need to be clever

Hi! while trying to use llvm::DominatorTreeBase on a custom graph that has nothing to do with llvm::BasicBlock I ran into some difficulties, because llvm::DominatorTreeBase calls e.g. getParent()->front() directly on the nodes and uses llvm::Inverse which forced me to implement my GraphTraits also for Inverse. This could be solved using a compile time abstraction of Graph instread of

On Sat, May 29, 2010 at 12:42 AM, Stéphane Letz <letz at grame.fr> wrote: > > Le 29 mai 2010 à 01:08, Bill Wendling a écrit : > >> Hi Stéphane, >> >> The SSE support is the LLVM backend is fine. What is the code that's generated? Do you have some short examples of where LLVM doesn't do as well as the equivalent scalar code? >> >> -bw >>

Given an instruction like this: br i1 %tmp12, label %bb5, label %bb6 I'm confused as to why Operand(1) = bb6 and not bb5 and why Operand(2) is bb5 and not bb6. Why in the instruction does the true path always list first but when accessing the operands of the instruction, it is backwards? Is there a particular reason for this? -------------- next part -------------- An HTML attachment was