GlobalISel equivalent to TargetLowering::expandISNAN.
Use it in AArch64 and add a testcase.
Paths
| Differential D108227
[GlobalISel] Implement lowering for G_ISNAN + use it in AArch64 ClosedPublic Authored by paquette on Aug 17 2021, 11:11 AM.
Details Summary GlobalISel equivalent to TargetLowering::expandISNAN. Use it in AArch64 and add a testcase.
Diff Detail Event TimelineHerald added subscribers: hiraditya, kristof.beyls, rovka. · View Herald TranscriptAug 17 2021, 11:11 AM This revision is now accepted and ready to land.Aug 17 2021, 11:46 PM This revision was landed with ongoing or failed builds.Aug 18 2021, 10:54 AM Closed by commit rG791006fb8c6f: [GlobalISel] Implement lowering for G_ISNAN + use it in AArch64 (authored by paquette). · Explain Why This revision was automatically updated to reflect the committed changes. simon_tatham added inline comments.
lebedev.ri added a reverting change: rG3f1f08f0ed6a: Revert @llvm.isnan intrinsic patchset..Sep 2 2021, 3:54 AM
Revision Contents
Diff 366960 llvm/include/llvm/CodeGen/GlobalISel/LegalizerHelper.h
llvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
llvm/test/CodeGen/AArch64/GlobalISel/legalize-isnan.mir
|
Sorry to be late spotting this, but I think this fptosi can't be right.
Surely what we need here is the integer that represents the encoding of the FP number, with sign, exponent and mantissa fields?
But this is computing the integer that represents its numerical value, as if from a source-level float→int conversion.
In the AArch64 output code I'm seeing, this fptosi is coming out as an FCVTZS w8,s0 instruction, and with a sensible single-precision NaN in s0 (encoding 0x7fc00000), that instruction is generating zero in w8, which leads to isnan(NaN) returning false.
I don't speak good MIR, but surely something like a bitcast would be the right operation.