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

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 17 10:32:32 PST 2020


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;
----------------
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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72930





More information about the llvm-commits mailing list