search for: rmnearesttiestoeven

...oatingPointExceptions(); ConstantFPSDNode *N1CFP = dyn_cast<ConstantFPSDNode>(N1.getNode()); ConstantFPSDNode *N2CFP = dyn_cast<ConstantFPSDNode>(N2.getNode()); if (N1CFP) { @@ -3415,28 +3416,32 @@ switch (Opcode) { case ISD::FADD: s = V1.add(V2, APFloat::rmNearestTiesToEven); - if (s != APFloat::opInvalidOp) + if (!HasFPExceptions || s != APFloat::opInvalidOp) return getConstantFP(V1, VT); break; case ISD::FSUB: s = V1.subtract(V2, APFloat::rmNearestTiesToEven); - if (s!=APFloat::opInvalidOp) + if (!HasFP...

...FP = dyn_cast<ConstantFPSDNode>(N1.getNode()); >> ConstantFPSDNode *N2CFP = dyn_cast<ConstantFPSDNode>(N2.getNode()); >> if (N1CFP) { >> @@ -3415,28 +3416,32 @@ >> switch (Opcode) { >> case ISD::FADD: >> s = V1.add(V2, APFloat::rmNearestTiesToEven); >> - if (s != APFloat::opInvalidOp) >> + if (!HasFPExceptions || s != APFloat::opInvalidOp) >> return getConstantFP(V1, VT); >> break; >> case ISD::FSUB: >> s = V1.subtract(V2, APFloat::rmNearestTiesToEven); >&gt...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...DNode>(N1.getNode()); ConstantFPSDNode *N2CFP = dyn_cast<ConstantFPSDNode>(N2.getNode()); if (N1CFP) { @@ -3416,30 +3415,32 @@ SDValue SelectionDAG::getNode(unsigned Opcode, SDLoc DL, EVT VT, SDValue N1, switch (Opcode) { case ISD::FADD: s = V1.add(V2, APFloat::rmNearestTiesToEven); - if (!HasFPExceptions || s != APFloat::opInvalidOp) + if (isSafeToOptimizeFPOp(s, APFloat::opInvalidOp)) return getConstantFP(V1, VT); break; case ISD::FSUB: s = V1.subtract(V2, APFloat::rmNearestTiesToEven); - if (!HasFPExceptions || s!=A...

...`` f bits: 0x34cc f as string: "2.998E-1" newF as string: "2.9956E-1" newF bits: 0x34cb ... Assertion `getBits(newF) == 0x34cc' failed. ``` As you can see when we create a new APFloat from the string we get a slightly smaller number. I have observed that if I use ``APFloat::rmNearestTiesToEven`` when creating ``newF`` that I do get an APFloat instance which has the same value as the original APFloat. So I'm wondering if the comment about round tripping APFloats only holds for certain rounding modes. Any thoughts on this? Thanks, Dan

This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and

...EVT VT = Node->getOperand(0).getValueType(); EVT NVT = Node->getValueType(0); APFloat apf(DAG.EVTToAPFloatSemantics(VT), APInt::getNullValue(VT.getSizeInBits())); APInt x = APInt::getSignBit(NVT.getSizeInBits()); (void)apf.convertFromAPInt(x, false, APFloat::rmNearestTiesToEven); Tmp1 = DAG.getConstantFP(apf, dl, VT); Tmp2 = DAG.getSetCC(dl, getSetCCResultType(VT), Node->getOperand(0), Tmp1, ISD::SETLT); True = DAG.getNode(ISD::FP_TO_SINT, dl, NVT, Node->getOperand(0)); // TODO: Should any fast-math-fla...

...dr, sizeof(Hdr)); Index: lib/Target/CBackend/CBackend.cpp =================================================================== --- lib/Target/CBackend/CBackend.cpp (revision 117247) +++ lib/Target/CBackend/CBackend.cpp (working copy) @@ -746,7 +746,7 @@ APF.convert(APFloat::IEEEdouble, APFloat::rmNearestTiesToEven, &ignored); #if HAVE_PRINTF_A && ENABLE_CBE_PRINTF_A char Buffer[100]; - sprintf(Buffer, "%a", APF.convertToDouble()); + snprintf(Buffer, sizeof(Buffer), "%a", APF.convertToDouble()); if (!strncmp(Buffer, "0x", 2) || !strncmp(Buffer, "-...

...> > EVT NVT = Node->getValueType(0); > > APFloat apf(DAG.EVTToAPFloatSemantics(VT), > > APInt::getNullValue(VT.getSizeInBits())); > > APInt x = APInt::getSignMask(NVT.getSizeInBits()); > > (void)apf.convertFromAPInt(x, false, APFloat::rmNearestTiesToEven); > > Tmp1 = DAG.getConstantFP(apf, dl, VT); > > Tmp2 = DAG.getSetCC(dl, getSetCCResultType(VT), > > Node->getOperand(0), > > Tmp1, ISD::SETLT); > > True = DAG.getNode(ISD::FP_TO_SINT, dl, NVT, Node->get...

Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select

> This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep > from introducing additional observable side-effects, and it's clear that whatever did this did not account > for floating point exception. That’s a very reasonable statement, but I’m not sure it corresponds to the way we have typically approached this sort of problem. In