search for: oeq

...hat http://llvm.org/docs/LangRef.html describes the difference between "ordered" and "unordered" as pertaining to QNAN operands, with no mention of negative zero. I tried fixing the issue, but then the following test in cast-int-fcmp-eq-0.ll fails: ; CHECK-LABEL: @i32_cast_cmp_oeq_int_n0_uitofp( ; CHECK: uitofp ; CHECK: fcmp oeq define i1 @i32_cast_cmp_oeq_int_n0_uitofp(i32 %i) { %f = uitofp i32 %i to float %cmp = fcmp oeq float %f, -0.0 ret i1 %cmp } Is this test really justified, or is it just reinforcing an oversight? - Arch D. Robison -------------- next part ---...

...ial value 6. return true or false if the values were equal. /** float gfloat = 3.141592; */ define i32 @test_getgfloat_0() { block_test_getgfloat_0: %0 = load float* @gfloat store float 0x400921FB00000000, float* @gfloat // wrong value stored %1 = call float @getgfloat() %2 = fcmp oeq float %1, 0x400921FA00000000 // wrong value stored %3 = zext i1 %2 to i32 store float %0, float* @gfloat ret i32 %3 } /** double gdouble = 2.52340; */ define i32 @test_getdouble_0() { block_test_getdouble_0: %0 = load double* @gdouble store double 2.523400e+00, double* @gdouble...

On Thu, Nov 8, 2018 at 11:35 PM Fabian Giesen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What is so complicated about these? Shouldn't they just correspond to > two compares + selects? > > To give a concrete example, x86 MIN[SP][SD] and MAX[SP][SD], > respectively, correspond exactly to > > MIN*: select(a < b, a, b) (i.e. "a < b ? a : b")

...erand(0)->getType() == getOperand(1)->getType() && "Both operands to FCmp instruction are not of the same type!"), function FCmpInst, file [snip]/clang/llvm/include/llvm/IR/Instructions.h, line 1117. We begin with a float "a" and double "b": > (fcmp oeq a, a) & (fcmp oeq b, b) After canonicalization in InstCombine, we end up with the expression: > (fcmp ord a, 0.0) & (fcmp ord b, 0.0) The bug manifest is in InstCombiner::FoldAndOfFCmps(FCmpInst *LHS, FCmpInst *RHS), when trying to perform this transformation: > (fcmp ord x, c) &a...

...%0 to <2 x i32> %2 = sitofp <2 x i32> %1 to <2 x float> %3 = fcmp ogt <2 x float> %0, zeroinitializer %4 = fadd <2 x float> %2, <float 1.000000e+00, float 1.000000e+00> %5 = select <2 x i1> %3, <2 x float> %4, <2 x float> %2 %6 = fcmp oeq <2 x float> %2, %0 %7 = select <2 x i1> %6, <2 x float> %0, <2 x float> %5 store <2 x float> %7, <2 x float>* %Cy118 %8 = load <2 x float>* %Cy118 store <2 x float> %8, <2 x float>* %Cy11a ret void } Thanks, David -------------- next...

...mmintrin.h> __m128i a(__m128 a, __m128 b, __m128 c) { return a==b & c==b; } The problem is that the IR going into Codegen has been (nicely) simplified to: define <2 x i64> @a(<4 x float> %a, <4 x float> %b, <4 x float> %c) nounwind readnone { entry: %cmp = fcmp oeq <4 x float> %a, %b ; <<4 x i1>> [#uses=1] %cmp4 = fcmp oeq <4 x float> %c, %b ; <<4 x i1>> [#uses=1] %and6 = and <4 x i1> %cmp, %cmp4 ; <<4 x i1>> [#uses=1] %and = sext <4 x i1> %and6 to <4 x i32> ; <<4 x i32>> [#u...

...t;4 x i32> %x, <4 x i32> %y) { %res = icmp eq <4 x i32> %y, %y ret %res } EOT llvm-as: <stdin>:2,0: Packed types not supported by icmp instruction % llvm-as <<'EOT' >/dev/null define i1 %cmpfint(<4 x float> %x, <4 x float> %y) { %res = fcmp oeq <4 x float> %y, %y ret %res } EOT llvm-as: <stdin>:2,0: Packed types not supported by fcmp instruction [2] From CmpInst::CmpInst: // Check that the operands are the right type assert(Op0Ty->isInteger() || isa<PointerType>(Op0Ty) || (isa<PackedType...

...%0 to <2 x i32> %2 = sitofp <2 x i32> %1 to <2 x float> %3 = fcmp ogt <2 x float> %0, zeroinitializer %4 = fadd <2 x float> %2, <float 1.000000e+00, float 1.000000e+00> %5 = select <2 x i1> %3, <2 x float> %4, <2 x float> %2 %6 = fcmp oeq <2 x float> %2, %0 %7 = select <2 x i1> %6, <2 x float> %0, <2 x float> %5 store <2 x float> %7, <2 x float>* %Cy118 %8 = load <2 x float>* %Cy118 store <2 x float> %8, <2 x float>* %Cy11a ret void } Thanks, David -------------------...

...t; %2 = sitofp <2 x i32> %1 to <2 x float> > %3 = fcmp ogt <2 x float> %0, zeroinitializer > %4 = fadd <2 x float> %2, <float 1.000000e+00, float 1.000000e+00> > %5 = select <2 x i1> %3, <2 x float> %4, <2 x float> %2 > %6 = fcmp oeq <2 x float> %2, %0 > %7 = select <2 x i1> %6, <2 x float> %0, <2 x float> %5 > store <2 x float> %7, <2 x float>* %Cy118 > %8 = load <2 x float>* %Cy118 > store <2 x float> %8, <2 x float>* %Cy11a > ret void > } >...

...e that EarlyCSE is interpreting the call to `ceil` and constant fold: *** IR Dump After Early CSE *** ; Function Attrs: nobuiltin nounwind define i1 @do_test() #2 { Entry: %0 = call fastcc float @ceil(float 0.000000e+00) #6 %1 = call fastcc float @ceil32(float 0.000000e+00) #6 %2 = fcmp fast oeq float 0.000000e+00, %1 ret i1 %2 } So just running `opt -early-cse -debug` seems enough: EarlyCSE Simplify: %0 = call fastcc float @ceil(float 0.000000e+00) #6 to: float 0.000000e+00 I suspect it is not correct from EarlyCSE to do that. -- Mehdi 2017-06-19 9:27 GMT-07:00 Andrew Kelley...

...N, the result is expected to be 0 then. If I run the bitcode with lli (JIT off), no problem. If I use the JIT (lli --force-interpreted=true), then it returns 1. (Converely, fcmp une with the JIT returns 0 instead of the expected 1 ... without JIT it returns the expected 0). The other operators (oeq, oge, ..., ueq, uge, ...) seem to work fine. Is this a bug with the JIT or have I done to muck this up? I've included source below which illustrates the problem (with doubles on fcmp one only ... ). Thanks for your help. ~ David declare void @exit(i32) declare void @llvm.memcpy.i32(i8*, i...

...{ > %res = icmp eq <4 x i32> %y, %y > ret %res > } > EOT > llvm-as: <stdin>:2,0: Packed types not supported by icmp instruction > % llvm-as <<'EOT' >/dev/null > define i1 %cmpfint(<4 x float> %x, <4 x float> %y) { > %res = fcmp oeq <4 x float> %y, %y > ret %res > } > EOT > llvm-as: <stdin>:2,0: Packed types not supported by fcmp instruction > > > > > [2] From CmpInst::CmpInst: > > > // Check that the operands are the right type > assert(Op0Ty->isInteger() |...

...mentptr inbounds i8* %0, i64 %23 ; <i8*> [#uses=1] %25 = load i8* %24 ; <i8> [#uses=1] %PeekResult11 = uitofp i8 %25 to double ; <double> [#uses=0] %26 = fsub double %22, %22 ; <double> [#uses=0] %27 = fcmp oeq double 0xC04FBB2E40000000, %22 ; <i1> [#uses=1] br i1 %27, label %Brancher4, label %Brancher7 Brancher7: ; preds = %Body6, %Body %28 = load i32* %BranchCounter ; <i32> [#uses=1] %"BrCounter++8" = add i32 %28, 1...

...(2.f * v1) > 0; } ; Function Attrs: norecurse nounwind readnone ssp uwtable define zeroext i1 @_Z2t1i(i32) #0 { %2 = icmp eq i32 %0, 5 ret i1 %2 } ; Function Attrs: norecurse nounwind readnone ssp uwtable define zeroext i1 @_Z2t2f(float) #0 { %2 = fadd float %0, 2.000000e+00 %3 = fcmp oeq float %2, 7.000000e+00 ret i1 %3 } ; Function Attrs: norecurse nounwind readnone ssp uwtable define zeroext i1 @_Z2t3i(i32) #0 { %2 = icmp sgt i32 %0, 0 ret i1 %2 } ; Function Attrs: norecurse nounwind readnone ssp uwtable define zeroext i1 @_Z2t4f(float) #0 { %2 = fmul float %0, 2.000000...

Yes, the modeling of floating-point is trickier. The wrap-around trick used by ConstantRange seems less applicable, and there are the unordered NaNs. Though in all cases, the key abstraction is a lattice of values, so an instance of FPRange should be thought of as a point on a lattice, not an interval. The lattice needs to be complicated enough the cover the cases of interest, but not so

...A!&7O!DAC-;Y4))GD\%\!*Q<P)-MC$P M-A#_!A`%`3M0*M0BP",P"?`$(/P[+75-6@`Q-#8RCY*/$?T&D&8$D"JQ;N`% MT"W@.Z#?9)$PX5W#-H$?46LUP`;POR0P>M$Q@@)@)Y!N[DE1</M?L@;@9)\! M)3$H(FSR97+_.H$#$`K!$K$L<#&"!X`N`KTF<'4FH1P0?.(QH&LQ$'\'X`:0 M,C,E`2[A.OEQ<G/\+V8+<'"@._5,D2NT,*7_'(`XDX_RD4,N\24PCY0T\_]@ M\2Y$46%;5W"3/L)4@#0--D@U8*.0;7^`,B!A</=ML2K0B0%D(:UACPN1&")9 M=Z`@2@Z!;G)"`B!DZ;!%3%,C8$63`@G@3Z;X3D5#1I!+(3$07%%E4N@H54MU M33P`P`,0)^#<.FJR!$B`LH%`CH$7H,42<"X%H"YU:U(?8A\O++V[3[E2&Z$` MO4`...

...void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i32, i1) #1 ; Function Attrs: nobuiltin nounwind define i1 @do_test() #2 !dbg !16 { Entry: %0 = call fastcc float @ceil(float 0.000000e+00) #6, !dbg !21 %1 = call fastcc float @ceil32(float 0.000000e+00) #6, !dbg !23 %2 = fcmp fast oeq float %0, %1, !dbg !24 ret i1 %2, !dbg !25 } ; Function Attrs: cold nobuiltin noreturn nounwind define linkonce coldcc void @__zig_panic(i8* nonnull readonly, i64) #3 !dbg !26 { Entry: %2 = alloca %"[]u8", align 8 %message_ptr = alloca i8*, align 8 %message_len = alloca i64, alig...

I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1:

...ing fast-math flags for only binary ops is straight-forward, but adding them for other ops might require a more involved bitcode change. I think that there might be some benefit to having flags for other kinds of ops, but those seem a bit more far-fetched and less common. For example, "fcmp N oeq x, x ==> true" or "bitcast N (bitcast N i32 %foo to float) to i32 ==> i32 %foo" seem more contrived than optimizations over binary ops. Comparisons are already sort of their own beast, as they ignore the sign of zero and have ordered and unordered versions. Given all that, I t...

I think I missed what problem we're trying to solve here. I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal (LLParser, etc) and set the corresponding SubclassOptionalData bits. Looking at LLVMBitCodes.h, I'm seeing where these bits reside in the bitcode, so I believe that things should be pretty straight-forward from