[PATCH] D137811: InstCombine: Perform basic isnan combines on llvm.is.fpclass

[Joshua Cranmer via Phabricator via llvm-commits]

jcranmer-intel added a comment.

In D137811#4095594 <https://reviews.llvm.org/D137811#4095594>, @sepavloff wrote:

> What about the original case, when `isnan` is used in inline function?
>
>   inline int get_code(float x) {
>     return isnan(x) ? 1 : 2;
>   }
>   #pragma STDC FENV_ACCESS ON
>   void func2(float x) {
>     int code1 = get_code(x);
>     ...
>   }
>
> Can this function, defined as non-strictfp, raise `Invalid` exception when inlined into strictfp function?

Since the function is non-`strictfp`, it's legal to optimize it in a way to raise spurious exceptions. //If// the `isnan` is retained at the time the function is inlined into a `strictfp` function, then it is no longer possible to optimize the //copy of `isnan` in the `strictfp` function// to raise spurious exceptions. But an optimization pass that runs before the inliner may still introduce spurious exceptions.

> There is a use case, when a computation is made with traps allowed for errors (Invalid, Overflow, DivideByZero). If an error occurs, computation is stopped. It saves from checks in multiple places during computation. The computation runs in default mode, because rounding mode is standard and precise exception flag behavior is unimportant. If non-strictfp functions are allowed to throw spurious exceptions, such solution won't work. Running computations in strictfp mode is not an option because of poor performance.

Enabling hardware traps for FP exceptions makes the FP environment no longer in the default mode, which requires the computation to be done in a `strictfp` function to have any defined behavior.


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

https://reviews.llvm.org/D137811