[PATCH] D72930: [FEnv] Constfold some unary constrained operations

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added inline comments.


================
Comment at: llvm/lib/IR/FPEnv.cpp:82
+  case fp::rmDynamic: return None;
+  case fp::rmToNearest: return APFloat::rmNearestTiesToAway;
+  case fp::rmDownward: return APFloat::rmTowardNegative;
----------------
sepavloff wrote:
> craig.topper wrote:
> > sepavloff wrote:
> > > craig.topper wrote:
> > > > rmToNearest should map to APFloat::rmNearestTiesToEven.
> > > > rmToNearest should map to APFloat::rmNearestTiesToEven
> > > 
> > > Why? It seems that the C11 standard (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf) does not specify which of two two IEEE-754 rounding modes corresponds to 'nearest'. Description of `round` however contains definite requirement (7.12.9.6):
> > > ```
> > > The round functions round their argument to the nearest integer value in floating-point
> > > format, rounding halfway cases away from zero, regardless of the current rounding
> > > direction.
> > > ```
> > > In this case rounding mode is `roundTiesToAway`. Why in other cases it must be `roundTiesToEven`?
> > As far as I know the default environment is supposed to be TiesToEven.  That's what all of the constant folding for non-strict FP assumes. The round function itself is weird and specifies a different behavior.
> Yes, I see that ConstantFolding.cpp uses mainly `roundTiesToEven` and will change the patch. It would be nice to understand why this is so.
> 
> What make me worry is unusual behavior of `roundTiesToEven`. For instance, 10.5 is rounded to 10.0. Behavior of `round` is more familiar.
The IEEE 754-2019 specification says this in section 4.3.3: "The roundTiesToEven rounding-direction attribute shall be the default rounding-direction attribute for results in binary formats." Although it describes roundTiesToAway, it says that rounding mode isn't required for binary format implementations.

More practically, I believe most hardware rounds ties to even when the round-to-nearest mode is selected. I know this is the case for x86 architecture processors. This is likely the behavior for all architectures that don't support both tie-breaking methods.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72930/new/

https://reviews.llvm.org/D72930