search for: tmp17

...phi int [ 0, %entry ], [ %i.0.0.ph, %cond_true ], [ %i.0.0.ph, %bb22 ], [ %tmp33, %bb31 ] ; <int> [#uses=5] %k.2.4 = phi int [ 0, %entry ], [ %tmp19, %cond_true ], [ 0, %bb22 ], [ 0, %bb31 ] ; <int> [#uses=3] %sum.0.4 = phi int [ 0, %entry ], [ %tmp17, %cond_true ], [ %tmp17, %bb22 ], [ %tmp17, %bb31 ] ; <int> [#uses=1] %tmp5 = getelementptr [7 x [7 x [7 x int]]]* %mat, int 0, int %i.0.0.ph, int %j.1.2.ph, int %k.2.4 ; <int*> [#uses=1] %tmp6 = load int* %tmp5 ; <int> [#uses=1]...

...00 > %tmp7.i.i = fdiv float 1.000000e+00, %tmp6.i.i > %tmp11.i.i = fsub float -0.000000e+00, %tmp53.i > %tmp13.i.i = fmul float %tmp53.i, %tmp11.i.i > %tmp15.i.i = fdiv float %tmp13.i.i, 2.000000e+00 > %call16.i.i = tail call float @llvm.exp.f32(float %tmp15.i.i) nounwind > %tmp17.i.i = fmul float %call16.i.i, 0x3FD9884540000000 > %tmp19.i.i = fmul float %tmp17.i.i, %tmp7.i.i > %tmp29.i.i = fmul float %tmp7.i.i, 0x3FF548CDE0000000 > %tmp30.i.i = fadd float %tmp29.i.i, 0xBFFD23DD40000000 > %tmp31.i.i = fmul float %tmp7.i.i, %tmp30.i.i > %tmp32.i.i = fadd f...

...20288 ; <i1> [#uses=3] %tmp14 = and i1 %tmp2, %tmp5 ; <i1> [#uses=1] %tmp15 = and i1 %tmp13, %tmp14 ; <i1> [#uses=1] tail call void @spa.assert(i1 %tmp15) %tmp16 = and i1 %tmp8, %tmp10 ; <i1> [#uses=1] %tmp17 = and i1 %tmp13, %tmp16 ; <i1> [#uses=1] tail call void @spa.assert(i1 %tmp17) %tmp18 = and i1 %tmp13, %tmp7 ; <i1> [#uses=1] tail call void @spa.assert(i1 %tmp18) ret void } Please notice the following code sequences are not optimal: %tmp5 =...

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

...ind readnone { %1 = icmp sgt i32 %x, 0 br i1 %1, label %bb.nph, label %3 bb.nph: ; preds = %0 %tmp4 = add i32 %x, -1 %tmp6 = add i32 %x, -2 %tmp16 = add i32 %x, -3 %tmp7 = zext i32 %tmp6 to i33 %tmp5 = zext i32 %tmp4 to i33 %tmp17 = zext i32 %tmp16 to i33 %tmp15 = mul i33 %tmp5, %tmp7 %tmp18 = mul i33 %tmp15, %tmp17 %tmp8 = mul i32 %tmp4, %tmp6 %tmp19 = lshr i33 %tmp18, 1 %2 = shl i32 %tmp8, 2 %tmp20 = trunc i33 %tmp19 to i32 %tmp12 = mul i32 %x, 5 %tmp1125 = and i32 %2, -8 %tmp21 = mul i3...

...{ entry: %0 = fadd float %aZ, 5.000000e-01 ; <float> [#uses=1] %1 = fadd float %aY, 5.000000e-01 ; <float> [#uses=1] %2 = fadd float %aX, 5.000000e-01 ; <float> [#uses=1] %tmp16.i.i = bitcast float %1 to i32 ; <i32> [#uses=1] %tmp17.i.i = zext i32 %tmp16.i.i to i96 ; <i96> [#uses=1] %tmp18.i.i = shl i96 %tmp17.i.i, 32 ; <i96> [#uses=1] %tmp19.i = zext i96 %tmp18.i.i to i128 ; <i128> [#uses=1] %tmp8.i = lshr i128 %tmp19.i, 32 ; <i128> [#uses=1] %tmp9.i...

...;" - Somewhere in my program, there is a store instruction: "store i32 %tmp31, i32* @ptr" it writes %tmp32 into memory, where @ptr pointed to (here: index 64 of value memory). - Afterward, another instruction needs to load the integer value '0' from value memory : "%tmp17 = mul i32 %mb_col, 0" It will try to read the value memory at index 64, but it is no more '0' but now %tmp31. So, the result is not correct ! I do not understand, how llvm handled this case. Anybody known it ? Thanks for any advice Quang

...t.tm* @localtime( i64* %curr ) br label %cond_next cond_false: %tmp16 = call %struct.tm* @gmtime( i64* %curr ) br label %cond_next cond_next: %storemerge = phi %struct.tm* [ %tmp15, %cond_true ], [ %tmp16, %cond_false ] store %struct.tm* %storemerge, %struct.tm** %iftmp.0 %tmp17 = load %struct.tm** %iftmp.0 store %struct.tm* %tmp17, %struct.tm** %tm ... ---------------------------------------------- Now, I need to figure out somehow that tmp15 and tmp16 are actually tm variable, but the generated code introduces another (redundant) level of indirection, which make...

...d float %aZ, 5.000000e-01 ; <float> [#uses=1] > %1 = fadd float %aY, 5.000000e-01 ; <float> [#uses=1] > %2 = fadd float %aX, 5.000000e-01 ; <float> [#uses=1] > %tmp16.i.i = bitcast float %1 to i32 ; <i32> [#uses=1] > %tmp17.i.i = zext i32 %tmp16.i.i to i96 ; <i96> [#uses=1] > %tmp18.i.i = shl i96 %tmp17.i.i, 32 ; <i96> [#uses=1] > %tmp19.i = zext i96 %tmp18.i.i to i128 ; <i128> [#uses=1] > %tmp8.i = lshr i128 %tmp19.i, 32 ; <i128> [#use...

...nk** @yythunks, align 4 %tmp9 = load i32* @yythunkpos, align 4 %tmp10 = load i32* @yythunkslen, align 4 %tmp11 = icmp slt i32 %tmp9, %tmp10 br i1 %tmp11, label %bb13, label %bb bb13: %tmp15.rle = phi i32 [ %tmp931, %entry ], [ %tmp9, %bb ] %tmp14 = load %struct.yythunk** @yythunks, align 4 %tmp17 = getelementptr %struct.yythunk* %tmp14, i32 %tmp15.rle, i32 0 store i32 %begin, i32* %tmp17, align 4 %tmp19 = load %struct.yythunk** @yythunks, align 4 %tmp20 = load i32* @yythunkpos, align 4 %tmp22 = getelementptr %struct.yythunk* %tmp19, i32 %tmp20, i32 1 store i32 %end, i32* %tmp22, align...

...is what "llvm-gcc -O2" gave me: define i32 @sum(i32 %n) nounwind { entry: %tmp215 = icmp eq i32 %n, 0 ; <i1> [#uses=1] br i1 %tmp215, label %bb10, label %tailrecurse.bb10_crit_edge tailrecurse.bb10_crit_edge: ; preds = %entry %tmp = add i32 %n, -1 ; <i32> [#uses=3] %tmp17 = mul i32 %tmp, %tmp ; <i32> [#uses=1] %tmp18 = add i32 %tmp17, %n ; <i32> [#uses=1] %tmp. = zext i32 %tmp to i64 ; <i64> [#uses=2] %tmp19 = add i64 %tmp., -1 ; <i64> [#uses=1] %tmp20 = mul i64 %tmp19, %tmp. ; <i64> [#uses=1] %tmp21 = lshr i64 %tmp20, 1 ; &l...

...label %bb.nph.i bb.nph.i: ; preds = %entry %.promoted1.i = load i32* %1, align 4 %tmp12.i = add i32 %a, -1 %tmp13.i = zext i32 %tmp12.i to i33 %tmp14.i = add i32 %a, -2 %tmp15.i = zext i32 %tmp14.i to i33 %tmp16.i = mul i33 %tmp13.i, %tmp15.i %tmp17.i = lshr i33 %tmp16.i, 1 %tmp18.i = trunc i33 %tmp17.i to i32 %tmp20.i = mul i32 %.promoted1.i, 5 %tmp21.i = add i32 %tmp20.i, -5 %tmp22.i = mul i32 %tmp21.i, %tmp12.i %tmp9.i = mul i32 %a, %a %.promoted2.i = load i32* %2, align 4 %tmp25.i = mul i32 %tmp18.i, 5 %tmp.i = sub i32 %.pr...

...elementptr %"struct.Q::BinaryOperation<bool,bool,bool,Q::AddOperator>"* %this, i32 0, i32 2, i32 0 ; <%"struct.Q::Function"**> [#uses=1] %tmp10.i = load %"struct.Q::Function"** %tmp9.i, align 4 ; < %"struct.Q::Function"*> [#uses=2] %tmp17.i = getelementptr %"struct.Q::BinaryOperation<bool,bool,bool,Q::AddOperator>"* %this, i32 0, i32 1, i32 0 ; <%"struct.Q::Function"**> [#uses=1] %tmp18.i = load %"struct.Q::Function"** %tmp17.i, align 4 ; < %"struct.Q::Function"*> [#u...

I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost as good with head). I'm running on Mac OS X 10.6. I have an apple supplied llvm-gcc and a self compiled llvm 2.8. When I run $ llvm-gcc -emit-llvm -S M.c $ opt -O2 M.s | llvm-dis I see that: 1. Tail recursion has been eliminated from wf 2. The accesses to sp have been promoted to registers 3. The loop has

Hi Ralf, > I do not understand why this behaviour is required. What is the problem > in having a function receive a single struct-parameter with three floats > compared to two scalar parameters? > > source-code (C++): > struct Test3Float { float a, b, c; }; > void test(Test3Float param, Test3Float* result) { ... } if you compile this with GCC, you will see that it too

Uh, sorry, did not pay attention where I was replying ;) Hey Duncan, I do not understand why this behaviour is required. What is the problem in having a function receive a single struct-parameter with three floats compared to two scalar parameters? source-code (C++): struct Test3Float { float a, b, c; }; void test(Test3Float param, Test3Float* result) { ... } bitcode:

On Thu, 9 Nov 2006, Ryan M. Lefever wrote: Sorry I never responded to this: > In the literature (see below for a reference), when a dominance frontier > is computed, it is computed from a CFG that contains a dummy entry node > and dummy exit node. Further, those dummy nodes are potential members > of the (post-)dominance frontier for a given basic block. In LLVM, I > could not

In the literature (see below for a reference), when a dominance frontier is computed, it is computed from a CFG that contains a dummy entry node and dummy exit node. Further, those dummy nodes are potential members of the (post-)dominance frontier for a given basic block. In LLVM, I could not figure out a way to determine if the dummy entry node is a member of the post-dominance frontier of