As for SETCC, use a less expensive condition code when generating
STRICT_FSETCC if the node is known not to have Nan.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
340 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
llvm/test/CodeGen/AArch64/arm64-fcmp-no-nans-opt.ll | ||
---|---|---|
2 | Since these tests run with -enable-no-nans-fp-math, I am wondering what condition we are testing: if ((FPMO && FPMO->hasNoNaNs()) || TM.Options.NoNaNsFPMath) I guess that is TM.Options.NoNaNsFPMath, so do we have/need checks for FPMO->hasNoNaNs()? |
But that check seems useful for float instructions? In other words, can we keep the check for FPMO->hasNoNaNs(), but just add some new tests for that?
llvm/test/CodeGen/AArch64/arm64-fcmp-no-nans-opt.ll | ||
---|---|---|
2 | Ah yes, this only makes sense for regular fcmp which can have fast math flag nnan. Constrained fcmp cannot. |
Constrained FCmp instructions cannot be given fast-math flags in textual IR currently. I'm not sure if there's a way for the flag to be propagated from somewhere else. I'll try to dig a bit more. Bear with me
Constrained fcmp can have such flags since any FPMathOperation can have the NoNaN flag but I could not find a way to set it from looking at the code. There are no parameter attribute that would achieve it, no easy way to express it with llvm.assume and no obvious combine that would work. Since there's no way to test that code I think it's safer to leave it out. Worst case it's an optimisation that does not happen and we can patch it later.
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | ||
---|---|---|
7010 | I'm not sure what you mean, something like: ISD::CondCode Condition = getFcmpCondCode(FPCmp->getPredicate()); if (TM.Options.NoNaNsFPMath) Opers.push_back(DAG.getCondCode(getFCmpCodeWithoutNaN(Condition))); else Opers.push_back(DAG>getCondCode(Condition)); ? I'd prefer to keep the current code since it mirrors what is done in visitFcmp and reflect better that even if a better condition code can be used (due to no NaN) we are still going to push it. YMMV of course. | |
llvm/test/CodeGen/AArch64/arm64-constrained-fcmp-no-nans-opt.ll | ||
3 ↗ | (On Diff #322205) | I've only done the f64 because f16 does not appear to be supported on AArch64: LLVM ERROR: Cannot select: 0x55d983a0fc58: f16,ch = AArch64ISD::STRICT_FCMP 0x55d9839a8938, 0x55d983a0fab8, 0x55d983a0fb88 0x55d983a0fab8: f16,ch = CopyFromReg 0x55d9839a8938, Register:f16 %0 0x55d983a0fa50: f16 = Register %0 0x55d983a0fb88: f16,ch = CopyFromReg 0x55d9839a8938, Register:f16 %1 0x55d983a0fb20: f16 = Register %1 In function: f16_constrained_fcmp_ueq Happy to add it later if someone adds that support. |
llvm/test/CodeGen/AArch64/arm64-constrained-fcmp-no-nans-opt.ll | ||
---|---|---|
3 ↗ | (On Diff #322205) | It is supported if you add -mattr=+fullfp16 to the command line. |
llvm/test/CodeGen/AArch64/arm64-constrained-fcmp-no-nans-opt.ll | ||
---|---|---|
3 ↗ | (On Diff #322205) | And without it, it shouldn't crash, so that is a problem, but perhaps a different one. |
I had to revert it because the testcase was failing on the bot. I rebased the patch yesterday and it was passing locally with f16 and f64. Maybe a change between yesterday and today. I'll try to reproduce and reopen the diff if it needs changing.
Remove f16 tests which is not yet supported by AArch64 backend: https://reviews.llvm.org/source/llvm-github/browse/main/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp$2277
@SjoerdMeijer Ok to commit without f16 tests given the above? I've tested in debug mode and thus assertion on this time and that passes without issue (fails in that mode with f16 cases)
Nit: perhaps just make this an if-else.