search for: bb16

...reg -instcombine -indvars -o bsloop-opt.bc bsloop.bc >you will get the following code for bsloop() function (llvm and >llvm-gcc-4.2 from SVN): >-------------------------------------------------------- >define void @bsloop(i32 %n, i32 %pM, %struct.Params* %ps) { >entry: > br label %bb16 > >bb1: ; preds = %bb8 > %tmp4 = call i32 (...)* @norm( i32 0, i32 1 ) > %indvar.next = add i32 %i.0, 1 > br label %bb8 > >bb8: ; preds = %bb16, %bb1 > %i.0 = phi i32 [ %indvar.next, %bb1 ], [ 0, %bb16 ] > %tmp11 = icmp slt i32 %i.0, %n > br i1 %tmp11, label %bb1,...

...d follow what you had suggested upto opt -analyze -loops bsloop-opt.bc Therefore, I could get the prints you had showed me as follows: -------------------------------------------------------- Printing analysis 'Natural Loop Construction' for function 'bsloop': Loop Containing: %bb16, %bb13, %bb8, %bb1 Loop Containing: %bb8, %bb1 -------------------------------------------------------- In your reply, you could re-construct the simple 'for' from the info above like this: -------------------------------------------------------- FOR %i.0 = 0 TO %n - 1 STEP 1: %tm...

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

...calculation. > 1736(%struct.FRAME.c974001* undef) > to label %invcont10 unwind label %lpad75 > > invcont10: ; preds = %invcont9 > invoke void @report__failed([0 x i8]* undef, %struct.RETURN* @C. > 168.1967) > to label %bb16 unwind label %lpad75 > > bb16: ; preds = %invcont10 > invoke fastcc void > @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean. > 1830(%struct.FRAME.c974001__timed_calculation__calculationA* undef) > to label...

...%struct.FRAME.c974001* undef) >> to label %invcont10 unwind label %lpad75 >> >> invcont10: ; preds = %invcont9 >> invoke void @report__failed([0 x i8]* undef, %struct.RETURN* @C. >> 168.1967) >> to label %bb16 unwind label %lpad75 >> >> bb16: ; preds = %invcont10 >> invoke fastcc void >> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean. >> 1830(%struct.FRAME.c974001__timed_calculation__calculationA* undef) &gt...

...;> to label %invcont10 unwind label %lpad75 >>> >>> invcont10: ; preds = >>> %invcont9 >>> invoke void @report__failed([0 x i8]* undef, %struct.RETURN* @C. >>> 168.1967) >>> to label %bb16 unwind label %lpad75 >>> >>> bb16: ; preds = >>> %invcont10 >>> invoke fastcc void >>> @c974001__timed_calculation__calculation__B19b__B21b__A17b___clean >>> . 1830(%struct.FRAME.c974001__timed_c...

...es=3] %exitcond = seteq uint %indvar, 3 ; <bool> [#uses=1] br bool %exitcond, label %bb10, label %bb3 bb10: ; preds = %bb8 %indvar.next27 = add uint %indvar26, 1 ; <uint> [#uses=2] %exitcond28 = seteq uint %indvar.next27, 10 ; <bool> [#uses=1] br bool %exitcond28, label %bb16, label %bb8.outer bb16: ; preds = %bb10 ret int %sum.1 } ------------------------------------------------------------- And I did "opt -reg2mem" for the bitcode, which is emitted like this: ------------------------------------------------------------- int %foo() { allocablock: %indvar2...

Hi Jakub, interesting patch. I ran it over the Ada testsuite and this picked up some problems even without enabling dse-ssu. For example, "opt -inline -dse -domtree" crashes on the attached testcase. Ciao, Duncan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dom_crash.ll URL:

Hello, This patch adds non-local DSE optimization. It uses Static Single Use representation. This is my first "big" patch, please be tolerant :-) Please note that optimization is disabled by default. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu.patch Type: application/octet-stream Size: 17352 bytes Desc: not available URL:

...following CFG: BB10 (malloc) / \ BB11 BB12 ... / \ / \ ... \ / \ / \ / BB13 BB14 BB15 | ... | / BB16 The block BB10 dominates BB11, BB12 and BB14. The dominance frontier of BB10 contains BB13, BB15 and BB16. So if the predecessors of the dominance frontier contains BB11, BB12 and BB14. If a call to free is inserted into BB11, BB12, and BB14, double free would occur. The problem boils down to this...

...malloc) > / \ > BB11 BB12 > ... / \ / \ ... > \ / \ / \ / > BB13 BB14 BB15 > | ... > | / > BB16 > > The block BB10 dominates BB11, BB12 and BB14. The dominance frontier of > BB10 contains BB13, BB15 and BB16. So if the predecessors of the dominance > frontier contains BB11, BB12 and BB14. If a call to free is inserted into > BB11, BB12, and BB14, double free would occur. The pr...

..._pn; /* LOOK HERE >*/ > //brlabel %bb8 > } > //bb10: > indvar_next27 = indvar26 + 1; > //%exitcond28 = setequint%indvar_next27, 10 > indvar26 = indvar_next27; > sum_0_pn_ph = sum_1; > //brbool %exitcond28, label %bb16, label %bb8_outer > } > //bb16: > return sum_1; >} > >int main() { > printf("%d\n", foo()); >} >$ gcc t.c >t.c: In function ‘main’: >t.c:40: warning: incompatible implicit declaration of built-in >function ‘printf’ >$ ./a.out >105 > &...

...t function > __do_global_dtors_aux: > subq $8, %rsp > movq %rbp, (%rsp) > movq %rsp, %rbp > cmpb $0, completed.4705(%rip) > jne .LBB1_4 #UnifiedReturnBlock > .LBB1_1: #bb9.preheader > movq p.4704(%rip), %rax > movq (%rax), %rax > cmpq $0, %rax > je .LBB1_3 #bb16 > .LBB1_2: #bb > addq $4, p.4704(%rip) > call *%rax > movq p.4704(%rip), %rax > movq (%rax), %rax > cmpq $0, %rax > jne .LBB1_2 #bb > .LBB1_3: #bb16 > movb $1, completed.4705(%rip) > movq %rbp, %rsp > popq %rbp > ret > .LBB1_4: #UnifiedReturnBlock &g...

...gt; movq %rsp, %rbp > > cmpb $0, completed.4705(%rip) > > jne .LBB1_4 #UnifiedReturnBlock > > .LBB1_1: #bb9.preheader > > movq p.4704(%rip), %rax > > movq (%rax), %rax > > cmpq $0, %rax > > je .LBB1_3 #bb16 > > .LBB1_2: #bb > > addq $4, p.4704(%rip) > > call *%rax > > movq p.4704(%rip), %rax > > movq (%rax), %rax > > cmpq $0, %rax > > jne .LBB1_2 #bb > > .LBB1_3: #bb16 > > movb $1, completed.4...

Dear Prof.Adve and Bill, I deeply appreciate your comments and concerns. (Please forgive my late response. I've tried some more cases to make this issue) As Prof.Adve mentioned, I need to explain exactly what my problem is, but I have no good ability that I can explain it in this plain text space. For this reason, I made a .pdf file and linked it as follows:

Hi all, I've run into problems compiling the llvm-gcc frontend on x86_64. Is this not supported, or am I making an error somewhere? The procedure I followed was: 1. Download LLVM 2.0 source as a tarball (from a few days ago, during the testing phase). 2. Download the llvm-gcc4 source today, as a tarball. 3. Extract both. 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install

> > It seems that placing the calls to free at the predecessors of dominance > frontier is inadequate. It is possible that there are exit blocks that are > dominated by BB12 (calls to malloc). I guess we can also insert calls to > free at these exit blocks too. That crossed my mind a few minutes later. : ) If you're interested, PRE.cpp existed last at r25315. It calculates the

Hi Henrique, Thanks for the quick reply! On Tue, Nov 12, 2013 at 9:13 PM, Henrique Santos < henrique.nazare.santos at gmail.com> wrote: > PRE normally uses a latest placement algorithm to do something of the sort. > I don't know about GVN/PRE, but older version of PRE might have it. > Just placing the calls to free at the predecessors (dominated by BB12) of > the dominance

...%_tmp88 = load %int4, %ptr7 %j.9 %_tmp89 = mul %int4 %_tmp88, 10 store %int4 %_tmp89, %ptr7 %j.9 %_tmp90 = load %int4, %ptr7 %i.8 %_tmp91 = add %int4 %_tmp90, 1 store %int4 %_tmp91, %ptr7 %i.8 %_tmp92 = load %int4, %ptr7 %j.9 %_tmp93 = icmp slt %int4 %_tmp92, 101 br i1 %_tmp93, label %bb14, label %bb16 bb16: br label %bb17 bb17: ret %int4 zeroinitializer }