search for: tmp19

...truct1 = type { i32, i32 } %struct2 = type { %struct1, %struct1 } ; Function Attrs: ssp uwtable define i32 @test1(%struct2* %dm, i1 %tmp4, i64 %tmp9, i64 %tmp19) { bb: br i1 %tmp4, label %bb1, label %bb2 bb1: ; preds = %bb5 %tmp10 = getelementptr inbounds %struc...

libcpp/charset.c:631 turns into: %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly ; <i64> [#uses=1] %tmp18 = tail call i64 @strlen( i8* %from ) nounwind readonly ; <i64> [#uses=1] %tmp19 = add i64 %tmp16, 2 ; <i64> [#uses=1] %tmp20 = add i64 %tmp19, %tmp18 ; <i64> [#uses=1] %tmp21 = tail call i8* @alloca( i64 %tmp20 ) nounwind ; <i8*> [#uses=5] other allocas in that file become instructions. Andrew On 2/16/08, Chris Lattner...

PR1711 is an x86 codegen problem that is blocking adoption of llvm-gcc by people using linux on x86-64 boxes. Could someone with access to one of these boxes take a look? I'll help try to debug this, but I don't have access to a machine. I bet it's a small tweak required in the x86 backend. Thanks! -Chris

...%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 float %tmp31.i.i, 0x3FFC80EF00000000 > %tmp33.i.i = fmul fl...

...18 %tmp13 = icmp slt i32 %tmp14, %tmp15 br i1 %tmp13, label %then11, label %else12 then11: %tmp20 = load i32* %f %tmp22 = alloca i32 store i32 1 , i32* %tmp22 %tmp23 = load i32* %tmp22 %tmp24 = load i32* %i %tmp21 = add i32 %tmp24, %tmp23 store i32 %tmp21, i32* %i %tmp19 = mul i32 %tmp20, %tmp21 store i32 %tmp19, i32* %f br label %then4 else12: %tmp25 = load i32* %f %tmp335 = getelementptr [4 x i8]* @.str1, i32 0, i32 0 %tmp336 = call i32 (i8*, ...)* @printf( i8* %tmp335, i32 %tmp25 ) ret i32 %tmp2...

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

...align 1 %tmp8 = zext i8 %tmp7 to i32 %tmp9 = shl nuw nsw i32 %tmp8, 16 %tmp10 = or i32 %tmp9, %tmp4 %tmp12 = getelementptr inbounds i8* %x_arg, i64 1 %tmp13 = load i8* %tmp12, align 1 %tmp14 = zext i8 %tmp13 to i32 %tmp15 = shl nuw nsw i32 %tmp14, 8 %tmp16 = or i32 %tmp10, %tmp15 %tmp19 = load i8* %x_arg, align 4 %tmp20 = zext i8 %tmp19 to i32 %tmp21 = or i32 %tmp16, %tmp20 ret i32 %tmp21 } attributes #0 = { nounwind readonly } --- Is there a reason why this can't be optimized down to a single i32 load based on the IR semantics, or is this just a missed optimization op...

...0, i32 3 ; <i8*> [#uses=1] store i8 104, i8* %tmp10, align 1 %tmp13 = getelementptr [8 x i8]* %str1, i32 0, i32 4 ; <i8*> [#uses=1] store i8 101, i8* %tmp13, align 1 %tmp16 = getelementptr [8 x i8]* %str1, i32 0, i32 5 ; <i8*> [#uses=1] store i8 114, i8* %tmp16, align 1 %tmp19 = getelementptr [8 x i8]* %str1, i32 0, i32 6 ; <i8*> [#uses=1] store i8 32, i8* %tmp19, align 1 %tmp22 = getelementptr [8 x i8]* %str1, i32 0, i32 7 ; <i8*> [#uses=1] store i8 0, i8* %tmp22, align 1 it's looks funny, can you say another less complex way to do this operation...

...> > > > then11: > > %tmp20 = load i32* %f > > %tmp22 = alloca i32 > > store i32 1 , i32* %tmp22 > > %tmp23 = load i32* %tmp22 > > %tmp24 = load i32* %i > > %tmp21 = add i32 %tmp24, %tmp23 > > store i32 %tmp21, i32* %i > > %tmp19 = mul i32 %tmp20, %tmp21 > > store i32 %tmp19, i32* %f > > br label %then4 > > > > else12: > > %tmp25 = load i32* %f > > %tmp335 = getelementptr [4 x i8]* @.str1, i32 0, i32 0 > > %tmp336 = call i32 (i8*, ...)* @printf( i8* %tmp335, i32 %tmp25 ) &...

...%tmp2227 = or i64 %tmp20, 1 %tmp2428 = or i64 %tmp20, 2 %tmp26 = trunc i64 %indvar10 to i32 br label %for.body25 for.body25: ; preds = %for.body25, %for.cond21.preheader %indvar4 = phi i64 [ 0, %for.cond21.preheader ], [ %indvar.next5, %for.body25 ] %tmp19 = shl i64 %indvar4, 2 %tmp21 = add i64 %tmp20, %tmp19 %arrayidx = getelementptr i8* %inputBuffer, i64 %tmp21 %tmp23 = add i64 %tmp2227, %tmp19 %arrayidx42 = getelementptr i8* %inputBuffer, i64 %tmp23 %tmp25 = add i64 %tmp2428, %tmp19 %arrayidx49 = getelementptr i8* %inputBuffer, i64 %tm...

...= %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 i32 %tmp20, 1431655764 %tmp13 = add i32 %tmp1125, %tmp12 %tmp14 = add i32 %tmp13, -4 %tmp22 = sub i32 %tmp14, %tmp21 ret i32...

...840 %tmp2227 = or i64 %tmp20, 1 %tmp2428 = or i64 %tmp20, 2 %tmp26 = trunc i64 %indvar10 to i32 br label %for.body25 for.body25: ; preds = %for.body25, %for.cond21.preheader %indvar4 = phi i64 [ 0, %for.cond21.preheader ], [ %indvar.next5, %for.body25 ] %tmp19 = shl i64 %indvar4, 2 %tmp21 = add i64 %tmp20, %tmp19 %arrayidx = getelementptr i8* %inputBuffer, i64 %tmp21 %tmp23 = add i64 %tmp2227, %tmp19 %arrayidx42 = getelementptr i8* %inputBuffer, i64 %tmp23 %tmp25 = add i64 %tmp2428, %tmp19 %arrayidx49 = getelementptr i8* %inputBuffer, i64 %tmp25 %...

...hibited the problem, but wanted to see it to think > through things properly. > > > > > > > > %struct1 = type { i32, i32 } > %struct2 = type { %struct1, %struct1 } > ; Function Attrs: ssp uwtable > define i32 @test1(%struct2* %dm, i1 %tmp4, i64 %tmp9, i64 %tmp19) { > bb: > br i1 %tmp4, label %bb1, label %bb2 > bb1: ; preds = %bb5 > %tmp10 = getelementptr inbounds %struct2* %dm, i64 %tmp9, i32 0 > br label %bb3 > > bb2: ; preds = %.lr.ph.i.i > %tmp20 = getelementptr inbounds %struct2* %dm, i64 %tmp9, i32 1 > br label %bb3 > &...

...=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 = trunc i128 %tmp8.i to i32 ; <i32> [#uses=1] %tmp10.i = bitcast i32 %tmp9.i to float ; <float> [#uses=1] store...

...romoted1.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 %.promoted1.i, %a %tmp10.i = add i32 %tmp9.i, 1 %tmp11.i = sub i32 %tmp10.i, %tmp18.i %tmp19.i = add i32 %tmp11.i, %.promoted2.i %tmp23.i = sub i32 %tmp20.i, %tmp25.i %tmp26.i = add i32 %tmp23.i, %tmp22.i store i32 0, i32* %0, align 4 store i32 %tmp19.i, i32* %2, align 4 store i32 %tmp.i, i32* %1, align 4 store i32 %tmp26.i, i32* %3, align 4 br label %wf.exit wf.exit:...

...r label %bb3 bb2: %tmp20 = getelementptr inbounds %struct2* %tmp1, i64 %tmp19 br label %bb3 bb3:...

...nt [ 0, %entry ], [ %j.1.2.ph, %cond_true ], [ %tmp24, %bb22 ], [ 0, %bb31 ] ; <int> [#uses=4] %i.0.0.ph = 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,...

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

...t %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 = trunc i128 %tmp8.i to i32 ; <i32> [#uses=1] > %tmp10.i = bitcast i32 %tmp9.i to float ; <float> [#u...

...gt; %tmp9 = shl nuw nsw i32 %tmp8, 16 > %tmp10 = or i32 %tmp9, %tmp4 > %tmp12 = getelementptr inbounds i8* %x_arg, i64 1 > %tmp13 = load i8* %tmp12, align 1 > %tmp14 = zext i8 %tmp13 to i32 > %tmp15 = shl nuw nsw i32 %tmp14, 8 > %tmp16 = or i32 %tmp10, %tmp15 > %tmp19 = load i8* %x_arg, align 4 > %tmp20 = zext i8 %tmp19 to i32 > %tmp21 = or i32 %tmp16, %tmp20 > ret i32 %tmp21 > } > > attributes #0 = { nounwind readonly } > --- > > Is there a reason why this can't be optimized down to a single i32 > load based on the IR sem...