search for: fcmp

...t for generating vcmp instead of vcmpe for equality comparisons. How come vcmpe is generated for (x!=x)? The answer is that InstCombine transforms the equality comparison into an "ordered comparison”. Before InstCombine: define dso_local i32 @bar(float %x) local_unnamed_addr { entry: %cmp = fcmp une float %x, %x %cond = select i1 %cmp, i32 0, i32 1 ret i32 %cond } After InstCombine: define dso_local i32 @bar(float %x) local_unnamed_addr #0 { entry: %cmp = fcmp ord float %x, 0.000000e+00 %cond = zext i1 %cmp to i32 ret i32 %cond } Please note that on other backends like x86 or A...

...rison to un > comparison + OR + ordered comparison ? > Can I do it by adding required SDNodes ? > for example I am trying to do it in LowerBR_CC as shown below: > getFPCCtoMBCC(CC,TCC); > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, > TargetCC); > if (isUnordered) { > TCC = XXX::COND_UN; > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > SDValue UnComp = DAG.getNode(XXX::FCMP, dl, MVT::Glue, LHS, RHS, >...

...ndya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU is available: > fcmp.un --> true if one of the operand is NaN > fcmp.lt --> ordered less than, if any input NaN then return false > fcmp.eq --> ordered equal, if any input NaN then return false > fcmp.le --> ordered less equal, if any input NaN then return false > fcmp.gt --> ordered grater t...

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN then return false fcmp.le --> ordered less equal, if any input NaN then return false fcmp.gt --> ordered grater than, if any input Na...

...ns about the clang front-end behavior / FENV_ACCESS). isunordered (like isnan) is a different operation from x!=x, in particular it does not signal even on signaling nans while x!=x does. > > As IR from clang with no optimization, this becomes a bunch of load/store > with: > %cmp = fcmp uno double %conv, %conv1 > > Ok, so far? "fcmp uno" - http://llvm.org/docs/LangRef.html#fcmp-instruction > : > uno: yields true if either operand is a QNAN. why is that ok? here you need an unordered-not-equal, but got an unordered-compare, the former is a silent ieee754 op...

...they should > return NaN if _either_ input is NaN, whereas the above will return NaN > if the second input (i.e. b) is NaN, but not if the first is. > > So we need to explicitly catch the case where a is NaN as well. For > minimum, that works out to something like: > > %3 = fcmp olt float %a, %b > %4 = select i1 %3, float %a, float %b ; (a < b) ? a : b > %5 = fcmp ord float %a, %a ; true if !isNaN(a) > %6 = select i1 %5, float %4, float %a ; if a was NaN, return a > > for the entire operation. The logic here is that if isNaN(a) || > isNaN(b),...

...lls. For the most part LLVM seems to get this right. For example define double @div(double %a, double %b) { %result = fdiv double %a, %b ret double %result } is expanded to a ISD::CALL of __divdf3 which is then lowered via the LowerOperation hook of my backend. However I run into problems with fcmp. With the following code: define i1 @fmp(double %a) { %result = fcmp uno double %a, 0.000000e+00 ret i1 %result } the fcmp is expanded to the a call to __unorddf2 which is then lowered via the LowerOperation hook of my backend. However for some reason there remains a ISD::CALL node with __unord...

...cember 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: >This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. Yes, that's the obvious alternative. I don't think we have any strong opinion either way, and fcmp/select is certainly easier to implement. -- Kevin Schoedel, Software Developer, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580

Maybe we can have two versions of the intrinsic function, "ordered" and "unordered", just like fcmp has [1]. Would that work ? [1] - http://llvm.org/docs/LangRef.html#fcmp-instruction On Dec 17, 2012, at 11:14 AM, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: >> Thi...

...fine double @div(double %a, double %b) { >> %result = fdiv double %a, %b >> ret double %result >> } >> >> is expanded to a ISD::CALL of __divdf3 which is then lowered via the >> LowerOperation hook of my backend. >> >> However I run into problems with fcmp. With the following code: >> >> define i1 @fmp(double %a) { >> %result = fcmp uno double %a, 0.000000e+00 >> ret i1 %result >> } >> >> the fcmp is expanded to the a call to __unorddf2 which is then >> lowered via the LowerOperation hook of my backend....

...right. For example > > define double @div(double %a, double %b) { > %result = fdiv double %a, %b > ret double %result > } > > is expanded to a ISD::CALL of __divdf3 which is then lowered via the > LowerOperation hook of my backend. > > However I run into problems with fcmp. With the following code: > > define i1 @fmp(double %a) { > %result = fcmp uno double %a, 0.000000e+00 > ret i1 %result > } > > the fcmp is expanded to the a call to __unorddf2 which is then > lowered via the LowerOperation hook of my backend. However for some > reason...

I am having a little trouble with the fcmp one instruction on doubles only. For ordered comparisons, the LLVM manual states that true should be returned iff neither operands is QNAN. ( http://llvm.org/docs/LangRef.html#i_fcmp) If I do fcmp one which includes one or both operands as a NaN, the result is expected to be 0 then. If I run th...

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero)...

...le %b) { >>> %result = fdiv double %a, %b >>> ret double %result >>> } >>> >>> is expanded to a ISD::CALL of __divdf3 which is then lowered via the >>> LowerOperation hook of my backend. >>> >>> However I run into problems with fcmp. With the following code: >>> >>> define i1 @fmp(double %a) { >>> %result = fcmp uno double %a, 0.000000e+00 >>> ret i1 %result >>> } >>> >>> the fcmp is expanded to the a call to __unorddf2 which is then >>> lowered via the Lo...

Hey guys, I've come across a bug when combining an AND of FCMPs. This bug occurs in my compiler as well as Clang built from trunk. A reduced test case is: int foo( float a, double b ) { return (a == a) & (b == b); } and the error is: Assertion failed: (getOperand(0)->getType() == getOperand(1)->getType() && "Both operands to FCmp i...

Are the ICMP and FCMP instructions meant to accept vectors operands or no? Verifier excludes vectors, as does the AsmParser[1]. But the CmpInst constructor accepts vectors[2], and they are documented as allowed: > If the operands [of icmp or fcmp] are packed typed, the elements of > the vector are compare...

...it tells us what happens for > real codes which Alive does not. Turns out that undef + fast math flags is enough to cause LLVM to become inconsistent: define i1 @f(i1 %a.is_nan, float %a, float %b) { %add = fadd nnan float %a, %b %sel = select i1 %a.is_nan, float undef, float %add %cmp = fcmp ord float %b, %sel ret i1 %cmp } When 'b' is NaN, the following occurs: %add = float undef %sel = float undef %cmp = i1 false However, the 'select i1 %A, %B, undef' -> 'undef' optimization permits us to transform @f to: define i1 @f(i1 %a.is_nan, float %a, float %b) {...

...algorithm used? As an aside, is there any documentation for the algorithm used? Is it based on a published paper? The input IR I have is the following: define <4 x float> @structurizer_test(<4 x float> %inp.coerce) { %1 = extractelement <4 x float> %inp.coerce, i32 0 %2 = fcmp ogt float %1, 0.000000e+00 br i1 %2, label %.lr.ph.i, label %._crit_edge.i .lr.ph.i: ; preds = %7, %0 %i.03.i = phi float [ %8, %7 ], [ 0.000000e+00, %0 ] %ret.02.i = phi <4 x float> [ %5, %7 ], [ <float 1.000000e+00, float 1.000000e+00, float...

...t = fdiv double %a, %b >>>> ret double %result >>>> } >>>> >>>> is expanded to a ISD::CALL of __divdf3 which is then lowered via the >>>> LowerOperation hook of my backend. >>>> >>>> However I run into problems with fcmp. With the following code: >>>> >>>> define i1 @fmp(double %a) { >>>> %result = fcmp uno double %a, 0.000000e+00 >>>> ret i1 %result >>>> } >>>> >>>> the fcmp is expanded to the a call to __unorddf2 which is then &gt...

....com> wrote: > But this is another case. LLVM IR distinguishes between ordered and unordered compare and X86 backend has appropriate instructions. I think LLVM uses ordered/unordered compare to mean something different to what the x86 instructions do. For example, "not equal": fcmp une == unordered not equal == A is NaN, B is NaN, or A != B fcmp one == ordered and equal == A is not NaN, B is not NaN, and A != B Both of these can be implemented with the x86 unordered comparison instruction by performing certain tests on the EFLAGS result. But if we used the comiss instruc...