[PATCH] D103169: [FPEnv][InstSimplify] Constrained FP support for undef, poison, and NaN

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

kpn added a comment.

In D103169#2782902 <https://reviews.llvm.org/D103169#2782902>, @spatel wrote:

> There's a lot going on here. I think we need to break this up to make sure we're testing the corner cases.
>
> What if we start with plain constant folding? I don't see any existing tests for these intrinsics in `llvm/test/Transforms/InstSimplify/ConstProp`. See `fp-undef.ll` in that dir for test ideas.
> For example, what can we do with this set of tests:
>
>   define float @fadd_undef_strict(float %x) #0 {
>     %r = call float @llvm.experimental.constrained.fadd.f32(float undef, float undef, metadata !"round.dynamic", metadata !"fpexcept.strict") #0
>     ret float %r
>   }
>   
>   define float @fadd_undef_maytrap(float %x) #0 {
>     %r = call float @llvm.experimental.constrained.fadd.f32(float undef, float undef, metadata !"round.dynamic", metadata !"fpexcept.maytrap") #0
>     ret float %r
>   }
>   
>   define float @fadd_undef_upward(float %x) #0 {
>     %r = call float @llvm.experimental.constrained.fadd.f32(float undef, float undef, metadata !"round.upward", metadata !"fpexcept.ignore") #0
>     ret float %r
>   }
>   
>   define float @fadd_undef_defaultfp(float %x) #0 {
>     %r = call float @llvm.experimental.constrained.fadd.f32(float undef, float undef, metadata !"round.tonearest", metadata !"fpexcept.ignore") #0
>     ret float %r
>   }
>
> What should happen if we replace each of those undef values with a constant number, NaN, etc?

Most of the changes are to thread exception behavior through functions that normally work with the normal FP instructions like fadd, fsub, etc.

The constrained intrinsics are then using the same code paths as those normal instructions. Which means that if the exception behavior isn't "fpexcept.strict" then with regards to undef, poison, and NaN you'll get identical results to using the regular FP instructions with identical first two operands. Some optimizations are disabled for non-default FP modes for now at least.

The constrained intrinsics with the _default_ FP mode will give you identical results to the regular instructions _including_ constant folding. At least through InstructionSimplify.cpp, anyway, with this patch.

I started where I did because InstructionSimplify.cpp's foldOrCommuteConstant() function calls into Analysis/ConstantFolding.cpp, but it doesn't yet pass through the rounding mode or exception behavior. So this actually seemed like it would be a smaller, more contained patch than jumping straight to InstSimplify's use of constant folding.

Serge Pavlov has a constant folding patch up as D102673 <https://reviews.llvm.org/D102673>.

I'm off the rest of the week and will be back on Tuesday, June 1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103169