[PATCH] D139032: InstCombine: Handle folding some negated is_fpclass mask test cases

[Matt Arsenault via Phabricator via llvm-commits]

arsenm created this revision.
arsenm added reviewers: sepavloff, spatel, kpn, cameron.mcinally, andrew.w.kaylor, efriedma, jcranmer-intel, jyknight, foad, nlopes.
Herald added subscribers: kosarev, hiraditya, Anastasia, tpr.
Herald added a project: All.
arsenm requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

Jay requested handling these in https://reviews.llvm.org/D137811

      

I realized these cases that turn class into fcmp are likely broken if
input denormals are treated as 0. However, this is so poorly specified
I'm not sure it's really wrong. alive2 says they're wrong for
denormals. Assuming is_fpclass does not read canonical inputs (as
might be implied by not trapping on snans), under DAZ,
is_fpclass(denorm, zero) is false and fcmp denorm, 0 is true.

      

The LangRef doesn't say anything about this for llvm.is.fpclass. The
AMDGPU class instruction does not consider the FP mode, and will see
denormal inputs as-is rather than the flush the input.

      

The only spec I know around denormal behavior is OpenCL's
-cl-denorms-are-zero, which doesn't clarify anything. It merely states
an implementation "can choose not to flush denorms to zero". It
doesn't specify whether this means outputs can be flushed, or if
inputs can be treated as 0s or what operations this applies to.

      

std::fpclassify does have a FP_SUBNORMAL result type. Under clang's
fcmp based implementation, it will return 0 for a denormal under DAZ.


https://reviews.llvm.org/D139032

Files:
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/Transforms/InstCombine/is_fpclass.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D139032.479006.patch
Type: text/x-patch
Size: 5162 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221130/67bd068f/attachment.bin>