[PATCH] D103169: [FPEnv][InstSimplify] Constrained FP support for NaN

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

In D103169#2879184 <https://reviews.llvm.org/D103169#2879184>, @qiucf wrote:

> Hi, I notice `poison` is generated for `maytrap` constrained `0 * Inf` operation, but `NaN` for non-constrained ones. Is that expected?
>
>   define float @foo() {
>   entry:
>     %x = tail call ninf contract afn float @llvm.experimental.constrained.fmul.f32(float 0.000000e+00, float 0x7FF0000000000000, metadata !"round.tonearest", metadata !"fpexcept.maytrap")
>     ret float %x
>   }
>   
>   # =>
>   
>   define float @foo() {
>   entry:
>     ret float poison
>   }
>
>
>
>   define float @foo() {
>   entry:
>     %x = fmul ninf contract afn float 0.000000e+00, 0x7FF0000000000000
>     ret float %x
>   }
>   
>   # =>
>   
>   define float @foo() {
>   entry:
>     ret float 0x7FF8000000000000
>   }
>
> Because constrained ones are handled by `simplifyFPOp` while non-constrained ones are handled by `ConstantFoldBinaryInstruction`. Should we make this consistent?

Yes, we should be consistent. The right, immediate fix for this is to have simplifyFPOp treat undef the same in the default and non-default FP environments. Right now the patch specifically excludes undef folding. This was done on purpose in this patch because of questions about how we're supposed to handle undef.

Is undef supposed to behave the same in all FP environments, default or not? I asked on llvm-dev and got no response: https://lists.llvm.org/pipermail/llvm-dev/2021-July/151727.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103169