search for: setlt

what's the semantics for setCC if one of the operands is NULL pointer? %ptr=alloc int seteq int*, %pt, NULL what's the result for the second instruction? How about setne, setlt, setgt, setle, and setge? Thanks! Jianzhong

...gt; [#uses=2] br bool %tmp.4, label %then, label %else then: ; preds = %no_exit %tmp.9 = mul int %i.0.0, 40 ; <int> [#uses=1] store int %tmp.9, int* %tmp.7 %inc9 = add int %i.0.0, 1 ; <int> [#uses=2] %tmp.112 = setlt int %inc9, 40 ; <bool> [#uses=1] br bool %tmp.112, label %no_exit, label %return else: ; preds = %no_exit %tmp.14 = mul int %i.0.0, %i.0.0 ; <int> [#uses=1] store int %tmp.14, int* %tmp.7 %inc = add int %i.0.0, 1...

I'm trying to fix PR12201, and would like some advice. Here's what is happening: On PPC32 VAARG is custom lowered (in PPCTargetLowering::LowerVAARG) and can create two ISD::SELECT nodes that use a ISD::SETCC node with a ISD::SETLT parameter. On PPC, ISD::SELECT is expanded, and here both of these SELECT nodes are expanded into ISD::SELECT_CC nodes with a ISD::SETLT node used by both. These SELECT_CC nodes are not directly instruction selected, instead they should be handled by the PPCDAGToDAGISel::Select function. This func...

..., label %else >> >> then: ; preds = %no_exit >> %tmp.9 = mul int %i.0.0, 40 ; <int> [#uses=1] >> store int %tmp.9, int* %tmp.7 >> %inc9 = add int %i.0.0, 1 ; <int> [#uses=2] >> %tmp.112 = setlt int %inc9, 40 ; <bool> [#uses=1] >> br bool %tmp.112, label %no_exit, label %return >> >> else: ; preds = %no_exit >> %tmp.14 = mul int %i.0.0, %i.0.0 ; <int> [#uses=1] >> store int %tmp.14, int* %tmp.7...

...t; [#uses=1] %Y = cast ubyte %SB to int ; <int> [#uses=1] FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/JavaCompare.ll: %c1 = setgt int %A, %B ; <bool> [#uses=1] %tmp = cast bool %c1 to int ; <int> [#uses=1] %c2 = setlt int %A, %B ; <bool> [#uses=1] %c31 = setlt int %tmp, 1 ; <bool> [#uses=1] %c3 = or bool %c2, %c31 ; <bool> [#uses=1] FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/cast-set.ll: %B = cast bool %A to int ; <int...

...bool %tmp.4, label %then, label %else > > then: ; preds = %no_exit > %tmp.9 = mul int %i.0.0, 40 ; <int> [#uses=1] > store int %tmp.9, int* %tmp.7 > %inc9 = add int %i.0.0, 1 ; <int> [#uses=2] > %tmp.112 = setlt int %inc9, 40 ; <bool> [#uses=1] > br bool %tmp.112, label %no_exit, label %return > > else: ; preds = %no_exit > %tmp.14 = mul int %i.0.0, %i.0.0 ; <int> [#uses=1] > store int %tmp.14, int* %tmp.7 > %inc =...

...; >>> then: ; preds = %no_exit >>> %tmp.9 = mul int %i.0.0, 40 ; <int> [#uses=1] >>> store int %tmp.9, int* %tmp.7 >>> %inc9 = add int %i.0.0, 1 ; <int> [#uses=2] >>> %tmp.112 = setlt int %inc9, 40 ; <bool> [#uses=1] >>> br bool %tmp.112, label %no_exit, label %return >>> >>> else: ; preds = %no_exit >>> %tmp.14 = mul int %i.0.0, %i.0.0 ; <int> [#uses=1] >>> store int...

...an = little target pointersize = 32 %.str_1 = internal constant [32 x sbyte] c"Boolean Not: %d %d %d %d %d %d\0A\00" ; <[32 x sbyte]*> [#uses=1] implementation ; Functions: declare int %printf(sbyte*, ...) void %testBooleanNot(int %A, int %B, int %C, int %D) { entry: %tmp.3 = setlt int %A, 1 ; <bool> [#uses=2] %tmp.4 = cast bool %tmp.3 to int ; <int> [#uses=2] ; br bool %tmp.3, label %shortcirc_done.0, label %shortcirc_next.0 br label %shortcirc_next.0 shortcirc_next.0: ; preds = %entry %tmp.9 = setlt int %C, 1 ; <bool> [#uses=2] %tmp.111 = c...

Before I file a bug, I thought I'd check to make sure something hasn't changed. Stacker used to work in 1.2, now it fails on six tests. All six tests pertain to use of the SetLT, SetGT, SetLE, and SetGE SetCondInst. In my test programs they all fail, regardless of the values. The *only* thing I've done to Stacker is to change the base type involved in the comparison from int to long. Is there something "different" about the comparison of longs? The code gen...

On Sun, 9 May 2004, Reid Spencer wrote: > Before I file a bug, I thought I'd check to make sure something hasn't > changed. Stacker used to work in 1.2, now it fails on six tests. All six > tests pertain to use of the SetLT, SetGT, SetLE, and SetGE SetCondInst. > In my test programs they all fail, regardless of the values. > > The *only* thing I've done to Stacker is to change the base type > involved in the comparison from int to long. Is there something > "different" about the comparison...

...sg = internal constant [15 x sbyte] c"Bottom'd Out!\0A\00" implementation ; Functions: declare int %printf(sbyte*, ...) internal void %stack_check() { entry: %xyzzy = alloca int ; <int*> [#uses=1] %spcheck.0 = cast int* %xyzzy to int %spcheck.1 = setlt int %spcheck.0, -1080000000 br bool %spcheck.1, label %the_return, label %endif endif: %tmp.0 = getelementptr [9 x sbyte]* %str_sp, int 0, int 0 %tmp.1 = call int (sbyte*, ...)* %printf( sbyte* %tmp.0, int* %xyzzy) call void %stack_check() br label %the_return...

...4 = getelementptr [12 x sbyte]* %a, int 0, uint %indvar ; <sbyte*> [#uses=2] %tmp.28 = load sbyte* %tmp.24 ; <sbyte> [#uses=1] %tmp.29 = add sbyte %tmp.28, 1 ; <sbyte> [#uses=1] store sbyte %tmp.29, sbyte* %tmp.24 %inc = add int %i.0.0, 1 ; <int> [#uses=1] %tmp.20 = setlt int %inc, %tmp.17 ; <bool> [#uses=1] %indvar.next = add uint %indvar, 1 ; <uint> [#uses=1] br bool %tmp.20, label %no_exit, label %loopexit So does it mean that I should insert all the IR code if I would like to insert a for loop in existed code. I can do it by inserting a call fun...

...ke or not. In reality, both "if" can't be taked at the > same time -- and that's why I'm trying to automatically figure out working on > LLVM representation. However, the LLVM code: > > int %logsch(int %ih, int %nbh) { > entry: > %tmp.1 = setlt int %nbh, 0 > %ih_addr.1 = select bool %tmp.1, int 10, int %ih > %nbh_addr.1 = select bool %tmp.1, int 0, int %nbh > %tmp.4 = setgt int %nbh_addr.1, 22528 > %ih_addr.0 = select bool %tmp.4, int 7, int %ih_addr.1 > %nbh_...

...uot;if" can't be taked at > > the same time -- and that's why I'm trying to automatically figure out > > working on LLVM representation. However, the LLVM code: > > > > int %logsch(int %ih, int %nbh) { > > entry: > > %tmp.1 = setlt int %nbh, 0 > > %ih_addr.1 = select bool %tmp.1, int 10, int %ih > > %nbh_addr.1 = select bool %tmp.1, int 0, int %nbh > > %tmp.4 = setgt int %nbh_addr.1, 22528 > > %ih_addr.0 = select bool %tmp.4, int 7, int %ih_addr.1 &gt...

Hello, I'm wondering what was the original motivaton for the 'select' instruction. Was it for convenience, or for some deep reason. I'm asking because it's causing me some problems (see below) and I'd like to know I understand the situation before working those problems around. I have the following function: int logsch(int ih,int nbh) { if(nbh < 0)

...case ISD::SETEQ: case ISD::SETOEQ: CondCode = XXXCC::COND_E; break; case ISD::SETGT: case ISD::SETOGT: CondCode = XXXCC::COND_GT; break; case ISD::SETGE: case ISD::SETOGE: CondCode = XXXCC::COND_GE; break; case ISD::SETOLT: case ISD::SETLT: CondCode = XXXCC::COND_LT; break; case ISD::SETOLE: case ISD::SETLE: CondCode = XXXCC::COND_LE; break; case ISD::SETONE: case ISD::SETNE: CondCode = XXXCC::COND_NE; break; case ISD::SETUO: CondCode = XXXCC::COND_UN; break; cas...

...es=1] %c.0.0 = cast uint %indvar to int ; <int> [#uses=1] %tmp.5 = add int %tmp.3.0, %k ; <int> [#uses=3] %tmp.10 = shl int %j.tmp.1, ubyte 1 ; <int> [#uses=1] %tmp.8 = add int %tmp.10, %k ; <int> [#uses=2] %inc = add int %c.0.0, 1 ; <int> [#uses=1] %tmp.2 = setlt int %inc, %k ; <bool> [#uses=1] %indvar.next = add uint %indvar, 1 ; <uint> [#uses=1] br bool %tmp.2, label %no_exit, label %loopexit.loopexit loopexit.loopexit: ; preds = %no_exit store int %tmp.5, int* %i load int* %i ; <int>:2 [#uses=1] store int %tmp.8, int* %j loa...

...x1500880: <multiple use> 0x15004c0: i32 = Constant <4294967295> 0x1500b50: <multiple use> 0x1500bb0: i1 = setcc 0x1500880, 0x15004c0, 0x1500b50 0x1500a00: <multiple use> 0x1500770: <multiple use> 0x1500ab0: ch = setlt 0x1500e90: i1 = setcc 0x1500a00, 0x1500770, 0x1500ab0 0x1500a00: <multiple use> 0x1500770: <multiple use> 0x1500b50: <multiple use> 0x1500c80: i1 = setcc 0x1500a00, 0x1500770, 0x1500b50 0x1500f60: i1 = select 0x1500bb0, 0x1500e90...

...= XXXCC::COND_E; > break; > case ISD::SETGT: > case ISD::SETOGT: > CondCode = XXXCC::COND_GT; > break; > case ISD::SETGE: > case ISD::SETOGE: > CondCode = XXXCC::COND_GE; > break; > case ISD::SETOLT: > case ISD::SETLT: > CondCode = XXXCC::COND_LT; > break; > case ISD::SETOLE: > case ISD::SETLE: > CondCode = XXXCC::COND_LE; > break; > case ISD::SETONE: > case ISD::SETNE: > CondCode = XXXCC::COND_NE; > break; > case ISD::SETUO...

...these if you assume that NULL is zero and alloca returns an unsigned nonzero pointer value. > what's the semantics for setCC if one of the operands is NULL pointer? > %ptr=alloc int > seteq int*, %pt, NULL > > what's the result for the second instruction? How about setne, setlt, > setgt, setle, and setge? Thanks! > > Jianzhong > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev -- gaeke at uiuc.edu