search for: unifiedreturnblock

...t;[6 x i8*]*> [#uses=0] define internal void @frame_dummy() { entry: %tmp1 = load i8** getelementptr ([0 x i8*]* @__JCR_LIST__, i32 0, i32 0), align 4 ; <i8*> [#uses=1] %tmp2 = icmp eq i8* %tmp1, null ; <i1> [#uses=1] br i1 %tmp2, label %UnifiedReturnBlock, label %bb bb: ; preds = %entry %tmp5 = tail call void (i8*)* (void (i8*)*)* asm "", "=r,0"( void (i8*)* @_Jv_RegisterClasses ) ; <void (i8*)*> [#uses=2] %tmp7 = icmp eq void (i8*)* %tmp5, null ; <i1> [#uses=1] br...

...ng test-case (a simple switch) through hyperblock-based DAGISel, and there's a pretty picture too! Each part of the switch is emitted directly into the DAG, rather than being deferred. This is the function: define i32 @foo(i32 %x, i32 %z) nounwind { entry: switch i32 %x, label %UnifiedReturnBlock [ i32 0, label %bb i32 1, label %bb5 ] bb: ; preds = %entry %tmp4 = mul i32 %z, %x ; <i32> [#uses=1] ret i32 %tmp4 bb5: ; preds = %entry %tmp8 = add i32 %z, %x ; <i32> [#uses...

...25 = load i32* @yypos, align 4 %tmp2627 = trunc i32 %tmp16 to i8 %tmp28 = getelementptr i8* %tmp24, i32 %tmp25 store i8 %tmp2627, i8* %tmp28, align 1 br label %cond_next cond_next: %iftmp.29.0 = phi i32 [ 1, %cond_true ], [ 0, %bb13 ] %tmp31 = icmp eq i32 %iftmp.29.0, 0 br i1 %tmp31, label %UnifiedReturnBlock, label %cond_next36 cond_next36: %tmp37 = load i32* @yylimit, align 4 %tmp39 = add i32 %tmp37, %iftmp.29.0 store i32 %tmp39, i32* @yylimit, align 4 ret i32 1 UnifiedReturnBlock: ret i32 0 } declare i8* @realloc(i8*, i32) declare i32 @_IO_getc(%struct._IO_FILE*) define i32 @yymatchDot() {...

...ertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label %gcov_version.exit ] cond_true.i: ; preds = %entry ret void gcov_version.exit: ; preds = %entry ret void UnifiedReturnBlock: ; preds = %entry ret void } ------------------------------------...

...through hyperblock-based DAGISel, and there's a pretty picture too! > Each part of the switch is emitted directly into the DAG, rather > than being deferred. > > This is the function: > define i32 @foo(i32 %x, i32 %z) nounwind { > entry: > switch i32 %x, label %UnifiedReturnBlock [ > i32 0, label %bb > i32 1, label %bb5 > ] > bb: ; preds = %entry > %tmp4 = mul i32 %z, %x ; <i32> [#uses=1] > ret i32 %tmp4 > bb5: ; preds = %entry > %tmp8 = add i32 %z, %x...

...%R1 %reg1026<def,dead> = MOVr %R1<kill>, 14, %reg0, %reg0 %reg1025<def> = MOVr %R0<kill>, 14, %reg0, %reg0 %reg1024<def> = MOVr %reg1025, 14, %reg0, %reg0 CMPri %reg1025<kill>, 0, 14, %reg0, %CPSR<imp-def> Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: Predecessors according to CFG: 0x8fdac90 (#0) %reg1027<def> = MOVi 0, 14, %reg0, %reg0 STR %reg1024<kill>, %reg1027<kil...

...frame_dummy > .text > # End of file scope inline assembly > > > .text > .align 16 > .type __do_global_dtors_aux, at 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:...

....text > > .align 16 > > .type __do_global_dtors_aux, at 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.47...

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

...rogram: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then: ; preds = %entry %tmp.3 = add int %p, 2 ; <int> [#uses=1] ret int %tmp.3 UnifiedReturnBlock: ; preds = %entry ret int 0 } int %_Z3fooi(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0...

...l?rev=192750&r1=192749&r2=192750&view=diff >> ============================================================================== >> --- llvm/trunk/test/CodeGen/X86/bt.ll (original) >> +++ llvm/trunk/test/CodeGen/X86/bt.ll Tue Oct 15 18:33:07 2013 >> @@ -38,7 +38,7 @@ UnifiedReturnBlock: ; preds = %entry >> define void @test2b(i32 %x, i32 %n) nounwind { >> entry: >> ; CHECK: test2b >> -; CHECK: btl %eax, %ecx >> +; CHECK: btl %e{{..}}, %e{{..}} >> ; CHECK: jb >> %tmp29 = lshr i32 %x, %n ; <i32> [#uses=...

...gt; # Machine code for Insert(): > Live Ins: R0 in VR#1025 R1 in VR#1026 > > entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: > Live Ins: %R0 %R1 > %LR<def> = MOVr %R0, 14, %reg0, %reg0 > CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def> > Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> > Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) > > bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: > Predecessors according to CFG: 0x8fdac90 (#0) > %R0<def> = MOVi 0, 14, %reg0, %reg0 > STR %LR<kill>, %R0&...

...t take the address of an intrinsic!", &I); This check appears to have a problem with this line: invoke void @llvm.memcpy.i32( i8* %._items.i.i, i8* %._items2.i.i, i32 ptrtoint (i32* getelementptr ([0 x i32]* null, i32 0, i32 4) to i32), i32 1 ) to label %UnifiedReturnBlock unwind label %failure ...in other words, it appears to be implying that it's not OK to use 'invoke' on an intrinsic. Is that correct? I should mention also that the code snipped above was produced by LLVM's optimizer, in my original code the call to memcpy was a call, not an in...

...**** Post Machine Instrs **** # Machine code for Insert(): Live Ins: R0 in VR#1025 R1 in VR#1026 entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: Live Ins: %R0 %R1 %LR<def> = MOVr %R0, 14, %reg0, %reg0 CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def> Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: Predecessors according to CFG: 0x8fdac90 (#0) %R0<def> = MOVi 0, 14, %reg0, %reg0 STR %LR<kill>, %R0<kill>, %reg0, 0...

...s=1] @a = weak global i32 0 ; <i32*> [#uses=1] define void @mai() nounwind { entry: %tmp = load float* @fl, align 4 ; <float> [#uses=1] %tmp1 = fcmp une float %tmp, 0.000000e+00 ; <i1> [#uses=1] br i1 %tmp1, label %bb, label %UnifiedReturnBlock bb: ; preds = %entry store i32 10, i32* @a, align 4 ret void UnifiedReturnBlock: ; preds = %entry ret void } 2) I generate code from the BC file using these e.g. options: llc --regalloc=linearscan -f cf1.c.bc -march=ia64 Could it be that llvm-...

...out that since eliminating these blocks requires no target-dependent information. However, I guess it is not worth eliminating them earlier. John, I tried your advice and executed opt (after -O3) again with -mergereturn and -simplifycfg: The -mergereturn pass introduces another basic block, called UnifiedReturnBlock, and replaces ret instructions with jumps to UnifiedReturnBlock. So, it does not eliminates any block but it creates one. (I think its task is to merge the ret instructions (and not the blocks).) The -simplifycfg pass does not affect my code at all. Moreover, according to 'StandardPasses.h...

...Ins: R0 in VR#1025 R1 in VR#1026 >>> >>> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: >>> Live Ins: %R0 %R1 >>> %LR<def> = MOVr %R0, 14, %reg0, %reg0 >>> CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def> >>> Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> >>> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) >>> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>> %R0<def> = MOVi 0, 14, %reg0, %reg0...

Eugene Toder wrote: > Would it make sense to have a similar pass that operates on llvm main IR? > The unify exit return node (-mergereturn?) pass should take care of the first example. The -simplifycfg option might take care of the second example. Both work on LLVM IR. -- John T. > On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen <dalej at apple.com> wrote: > >>

...sert(): >> Live Ins: R0 in VR#1025 R1 in VR#1026 >> >> entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: >> Live Ins: %R0 %R1 >> %LR<def> = MOVr %R0, 14, %reg0, %reg0 >> CMPri %R0<kill>, 0, 14, %reg0, %CPSR<imp-def> >> Bcc mbb<UnifiedReturnBlock,0x8fdad70>, 10, %CPSR<kill> >> Successors according to CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) >> >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> STR %...

Would it make sense to have a similar pass that operates on llvm main IR? On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen <dalej at apple.com> wrote: > The branch folding pass does this, but it operates later, on the > target-dependent form in llc. > > On May 8, 2010, at 8:48 AM, Heinz Riener wrote: > >> Dear all, >> >> after optimizing a small LLVM example