search for: tmp11

On Mon, Apr 27, 2015 at 4:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > You can't win here (believe me, i've tried, and better people than me have > tried, for years :P). > No matter what you do, the partitioning will never be 100% precise. The > only way to solve that in general is to pairwise query over the > partitioning. > > Your basic problem is

...2* %xx, i32* %yy) nounwind %tmp8 = load i32* %xx, align 4, !dbg !1026 ; <i32> [#uses=1] %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; <i16> [#uses=1] store i16 %tmp9, i16* %x, align 2, !dbg !1026 %tmp10 = load i32* %yy, align 4, !dbg !1027 ; <i32> [#uses=1] %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; <i16> [#uses=1] store i16 %tmp11, i16* %y, align 2, !dbg !1027 ret void return: ; preds = %entry ret void } define internal void @point_DIRECT_SPEC(i16* %x, i16* %y, %struct.termbox* %arg) nounwind {...

Here's an example where llvm should probably be producing smaller code, its output is 700% larger than gcc. regehr at john-home:~/volatile/tmp11$ llvm-gcc -Os -w small.c -o small ; size small text data bss dec hex filename 6324 252 8 6584 19b8 small regehr at john-home:~/volatile/tmp11$ current-gcc -Os -w small.c -o small ; size small text data bss dec hex filename 784 252...

...p61.i) nounwind > %tmp63.i = fmul float %tmp9.i, %call62.i > %call.i.i = tail call float @fabs(float %tmp53.i) nounwind > %tmp5.i.i = fmul float %call.i.i, 0x3FCDA67120000000 > %tmp6.i.i = fadd float %tmp5.i.i, 1.000000e+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....

Holger, I have just committed a patch to cause the linker to properly propagate error messages from the LinkModules method up to higher levels of the linker. With this change it should tell you with more detail what is going on (why it couldn't link the file in). Please update, rebuild and try again. If you think the error message is wrong after that, please file a bug for this. To get

...s=2] %tmp7 = icmp eq i32 %tmp6, 168296704 ; <i1> [#uses=1] %tmp8 = icmp eq i32 %tmp3, 168296448 ; <i1> [#uses=2] %tmp9 = icmp ne i32 %tmp6, 168296704 ; <i1> [#uses=1] %tmp10 = and i1 %tmp8, %tmp9 ; <i1> [#uses=1] %tmp11 = load i32* @src-ip ; <i32> [#uses=1] %tmp12 = and i32 %tmp11, -16777216 ; <i32> [#uses=1] %tmp13 = icmp eq i32 %tmp12, 721420288 ; <i1> [#uses=3] %tmp14 = and i1 %tmp2, %tmp5 ; <i1> [#uses=1] %tmp15 = and...

...the existing tests (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some interesting code. The IR is very straightforward: define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) { entry: ret i32 %a3 } define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { entry: %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32 %in1, i32 %in2) ret i32 %tmp11 } define i32 @foo(i32 %in1, i32 %in2) { entry: %q = call fastcc i32 @tailcaller(i32 %in2, i32 %in1) %ww = sub i32 %q, 6 ret i32 %ww } Built with (ToT LLVM): llc < ~/temp/z.ll -march=x86 -tailcallo...

> I think I have experienced this when more than one module > contains definitions for the same values. ie. it should only > be a declaration in one of them. Hmm, when I compile and link this with plain gcc, it everything works. Anyway, llvm-ld should probably not just say "Cannot link file 'blah'", but why it cannot link it. I compiled llvm in with --enable-debug.

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

...; <i32> [#uses=4] %i.0.reg2mem.0 = sub i32 255, %indvar ; <i32> [#uses=2] %tmp7 = getelementptr i32* %alp, i32 %i.0.reg2mem.0 ; <i32*> [#uses=1] %tmp8 = load i32* %tmp7, align 4 ; <i32> [#uses=1] %tmp11 = getelementptr i32* %lam, i32 %i.0.reg2mem.0 ; <i32*> [#uses=1] store i32 %tmp8, i32* %tmp11, align 4 %tmp13 = sub i32 254, %indvar ; <i32> [#uses=1] %tmp16 = icmp slt i32 %tmp13, 0 ; <i1> [#uses=1] %indvar.next = add i...

...d > %tmp8 = load i32* %xx, align 4, !dbg !1026 ; <i32> [#uses=1] > %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; <i16> [#uses=1] > store i16 %tmp9, i16* %x, align 2, !dbg !1026 > %tmp10 = load i32* %yy, align 4, !dbg !1027 ; <i32> [#uses=1] > %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; <i16> [#uses=1] > store i16 %tmp11, i16* %y, align 2, !dbg !1027 > ret void > > return: ; preds = %entry > ret void > } > > > define internal void @point_DIRECT_SPEC(i16* %x,...

...), I ran into IR that produces some > interesting code. The IR is very straightforward: > > define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 > %a4) { > entry: > ret i32 %a3 > } > > define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { > entry: > %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32 > %in1, i32 %in2) > ret i32 %tmp11 > } > > define i32 @foo(i32 %in1, i32 %in2) { > entry: > %q = call fastcc i32 @tailcaller(i32 %in2, i32 %in1) > %ww = sub i32 %q, 6 > ret i32 %ww > } > > Built wi...

...tmp5, align 8, !tbaa !2 > %tmp7 = fadd float %tmp4, %tmp6 > store float %tmp7, float* %tmp3, align 16, !tbaa !2 > %tmp8 = or i64 %k.01, 1 > %tmp9 = shl nsw i64 %tmp8, 1 > %tmp10 = getelementptr inbounds [1024 x float], [1024 x float]* > @x, i64 0, i64 %tmp9 > %tmp11 = load float, float* %tmp10, align 8, !tbaa !2 > %tmp12 = getelementptr inbounds [1024 x float], [1024 x float]* > @y, i64 0, i64 %tmp8 > %tmp13 = load float, float* %tmp12, align 4, !tbaa !2 > %tmp14 = fadd float %tmp11, %tmp13 > store float %tmp14, float* %tmp10, align...

I am testing vectorization on the following test case: float x[1024], y[1024]; void myloop1() { for (long int k = 0; k < 512; k++) { x[2*k] = x[2*k]+y[k]; } } Vectorization failed due to "unsafe dependent memory operation". I traced the LoopAccessAnalysis.cpp and found the reason is the NoWrapFlag for SCEVAddRecExpr is not set and consequently the

...%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 %.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, alig...

...bal i8* null @yylimit = global i32 0 @yypos = global i32 0 @yybuflen = global i32 0 @stdin = external global %struct._IO_FILE* @yy = weak global i32 0 define i32 @yyrefill() { entry: %tmp842 = load i32* @yybuflen, align 4 %tmp943 = load i32* @yypos, align 4 %tmp1044 = sub i32 %tmp842, %tmp943 %tmp1145 = icmp slt i32 %tmp1044, 512 br i1 %tmp1145, label %bb, label %bb13 bb: %tmp2.rle = phi i32 [ %tmp842, %entry ], [ %tmp8, %bb ] %tmp3 = shl i32 %tmp2.rle, 1 store i32 %tmp3, i32* @yybuflen, align 4 %tmp5 = load i8** @yybuf, align 4 %tmp6 = tail call i8* @realloc( i8* %tmp5, i32 %tmp3 ) st...

...interesting code. The IR is very straightforward: >> >> define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 >> %a4) { >> entry: >> ret i32 %a3 >> } >> >> define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { >> entry: >> %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32 >> %in1, i32 %in2) >> ret i32 %tmp11 >> } >> >> define i32 @foo(i32 %in1, i32 %in2) { >> entry: >> %q = call fastcc i32 @tailcaller(i32 %in2, i32 %in1) >> %ww = sub i32 %q, 6 >> r...

...<---tailcall.ll --->> @.str = internal constant [12 x i8] c"result: %d\0A\00" ; <[12 x i8] *> [#uses=1] define fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) { entry: ret i32 %a3 } define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { entry: %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 % in2, i32 %in1, i32 %in2 ) ; <i32> [#uses=1] ret i32 %tmp11 } define i32 @main(i32 %argc, i8** %argv) { entry: %argc_addr = alloca i32 ; <i32*> [#uses=1] %argv_addr = alloca i8** ; <i8***> [#uses=1]...

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

...ine linkonce_odr void @_ZN9__gnu_cxx13new_allocatorIjE9constructEPjRKj(%"class.__gnu_cxx::new_allocator"* %this, i32* %__p, i32* %__val) align 2 The callsite is: call void @_ZN9__gnu_cxx13new_allocatorIjE9constructEPjRKj(%"class.__gnu_cxx::new_allocator"* %3, i32* %tmp10, i32* %tmp11) Does anybody have a clue what could be wrong or what has to be checked before executing? Best Andreas