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

Kevin P. Neal via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 6 11:32:54 PDT 2021


kpn added inline comments.


================
Comment at: llvm/test/Transforms/InstSimplify/fast-math-strictfp.ll:65
+;
+  %negx = call float @llvm.experimental.constrained.fsub.f32(float -0.0, float %x, metadata !"round.tonearest", metadata !"fpexcept.ignore") #0
+  %r = call nnan float @llvm.experimental.constrained.fadd.f32(float %negx, float %x, metadata !"round.tonearest", metadata !"fpexcept.ignore") #0
----------------
spatel wrote:
> Not part of this patch, but is the plan to convert the constrained op(s) into regular ops in this situation?
No. Mixing of regular FP ops and constrained ops in a single function is not allowed since we can't prevent harmful reordering. So the only case where it might be legal is where an entire function uses the constrained intrinsics in the default FP environment. In that case ... why are the constrained intrinsics being used, anyway?


================
Comment at: llvm/test/Transforms/InstSimplify/fp-undef-poison-strictfp.ll:74
 ; CHECK-LABEL: @fadd_poison_op0_defaultfp(
-; CHECK-NEXT:    [[R:%.*]] = call float @llvm.experimental.constrained.fadd.f32(float poison, float [[X:%.*]], metadata !"round.tonearest", metadata !"fpexcept.ignore") #[[ATTR0]]
-; CHECK-NEXT:    ret float [[R]]
+; CHECK-NEXT:    ret float 0x7FF8000000000000
 ;
----------------
spatel wrote:
> There was a bug in poison propagation -- hopefully fixed with 4ec7c021970d -- but that doesn't explain why this and similar tests below are not returning poison. Update/regenerate the CHECK lines?
Will do, tomorrow.


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

https://reviews.llvm.org/D103169



More information about the llvm-commits mailing list