[PATCH] D102673: [ConstantFolding] Fold constrained arithmetic intrinsics

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added inline comments.


================
Comment at: llvm/lib/Analysis/ConstantFolding.cpp:1907
+    // Even if the rounding mode is unknown, try evaluating the operation.
+    // If it does not raise inexact exception, rounding was not applied
+    // so the result does not depend on rounding mode.
----------------
spatel wrote:
> This code comment does not look accurate.
> When we speculatively evaluate the expression, we check that *any* exception was not raised, not just the inexact exception, right?
> 
> This raises a question: if we evaluate the expression using NearestTiesToEven, then are we guaranteed that all potential exceptions (even underflow) are identical to any other rounding mode?
> This code comment does not look accurate.
> When we speculatively evaluate the expression, we check that *any* exception was not raised, not just the inexact exception, right?

Yes. If exceptions are tracked and constant evaluation can raise any of them, constant expression is not folded. The relevant logic is implemented by `mayFoldConstrained`, which is defined above. It is necessary to set hardware state, which is expected as side effect of the evaluation.

The purpose of this rounding mode substitution is to enable constant folding of expressions like `1.0 + 1.0` even when rounding mode is dynamic, so unknown at compile time. 

I tried to reword the comment to make it clearer.

> This raises a question: if we evaluate the expression using NearestTiesToEven, then are we guaranteed that all potential exceptions (even underflow) are identical to any other rounding mode?

IEEE-754 compliant system evaluates an operation in two steps. First it calculates intermediate result as if both the exponent range and the precision were unbounded. Then this result is rounded if it cannot be represented in the chosen floating point format. The first step does not depend on rounding mode but the second does.

Of the five FP exception `division-by-zero` and `invalid` obviously do not depend on rounding mode. `Overflow` is raised when the intermediate result is too large by magnitude to be represented in the chosen floating point format. Similar considerations apply to `underflow` as well. As for `inexact` exception, if it is raised, it means the intermediate result cannot be exactly represented and the rounding step changed it to either of nearby values. The direction is determined by rounding mode but rounding is required in any rounding mode.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102673