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

Tue Jan 31 15:46:49 PST 2023

jyknight added a comment.

I do not believe there's any problem with an isnan to fcmp transform -- as long as we restrict it to non-strictfp functions. And I'm not sure why there's so much debate here. I thought all those sorts of semantic questions were already pretty well settled. Does the documentation about strictfp vs not-strictfp semantics need to be made clearer?

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

>   The C classification macros fpclassify, iscanonical, isfinite, isinf, isnan, isnormal,
>   issignaling, issubnormal, iszero, and signbit provide the IEC 60559 operations indicated
>   in the table above provided their arguments are in the format of their semantic type. Then these
>   macros raise no floating-point exceptions, even if an argument is a signaling NaN.
>
> and this property must be kept no matter if exceptions are ignored or not.

No, the property does not need to be maintained if the exception flag state cannot be observed by correct code. And that's exactly the case at hand in FENV_ACCESS OFF code (and, correspondingly, non-strictfp in LLVM IR). In such code, you are not allowed to have trap-on-exception enabled, nor are you allowed to access the floating-point exception status flags, and, the state of the status flags is unspecified upon transitioning back to FENV_ACCESS ON code. Thus, within such code, we may set the status flags to any arbitrary value we wish -- nobody can (correctly) tell the difference.

> In a broader context, it looks natural that a non-strictfp function may lose some exceptions that strictfp function would raise. But it would be counterintuitive if it raised new exceptions, which cannot be observed in strictfp function.

That's not a problem. It is definitely permissible for a non-strictfp function to raise an FP-exceptions that "should not" be raised. That this is permissible is one of the most important properties of the non-strict operations -- it allows code motion which is impermissible if the status-flag side effects must be taken into account. (e.g. speculating an "fadd" above a conditional).

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

https://reviews.llvm.org/D137811