[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