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

[Craig Topper via Phabricator via llvm-commits]

craig.topper 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;
----------------
andrew.w.kaylor wrote:
> 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.
roundTiestoAway is more familiar because its what we're taught in school when we're young. But it introduces bias in the results. Rounding to even can cancel out some bias. See the "round half to even" section here https://en.wikipedia.org/wiki/Rounding


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72930