Libcall __gcc_qtou is not available, which breaks some tests needing it. On PowerPC, we have code to manually expand the operation, this patch applies it to constrained conversion.
Details
- Reviewers
jsji steven.zhang nemanjai kbarton hfinkel uweigand - Group Reviewers
Restricted Project - Commits
- rG705271d9cd0e: [PowerPC] Expand constrained ppc_fp128 to i32 conversion
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Run clang-format.
llvm/lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
8208 | Should we create STRICT_FSELECT_CC/STRICT_FSELECT_CCS with intrinsics..? |
The algorithm used in the unsigned case isn't strict-safe. However, this is exactly the same algorithm that is also used in TargetLowering::expandFP_TO_UINT, where is has been made properly strict-safe in the meantime.
You should simply copy that algorithm here. The only difference is that there we target i64, while here we target i32, so the constants have to be updated accordingly.
In the signed case, the only issue is see is that PPCISD::FADDRTZ might throw an exception, and we therefore should be using a strict variant of it here (and chain it in accordingly).
llvm/lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
8206 | Just a minor nit: this should be the same constant that the non-strict code also uses. It seems better to create the constant in the same way (code can be shared between both cases). | |
llvm/lib/Target/PowerPC/PPCInstrInfo.td | ||
2970 | You should verify the FADDrtz custom inserter works correctly for the strict case. I believe it should transfer the no-exception flag to the FADD it generates in the end. |
- Move out constants
- Transfer nofpexcept flag. If this is a problem, other lowering methods should also be fixed
- Transfer nofpexcept to FADD if FADDRtz is nofpexcept
llvm/lib/Target/PowerPC/PPCInstrInfo.td | ||
---|---|---|
2970 | Thanks for pointing out this. Actually, I see here FADD is always NOT nofpexcept unless transfer this flag from FADDRtz to it. Besides, I notice if we use !metadata "fpexcept.ignore, FADDRtz doesn't obtain nofpexcept flag. That's because we dropped SD flags in lowering these nodes while they're target strict opcodes, so seen as may raise exception. Similar flag missing is also seen on X86 (not tested other targets), a constrained fptoui from double to i64 would be lowered to fptosi. The flag missed during this. |
llvm/lib/Target/PowerPC/PPCInstrInfo.td | ||
---|---|---|
2970 | Hmm, interesting. I agree the NoFPExcept flag should be transfered over. I'm not actually sure it is correct to transfer *all* the flags to all the operations. There's actually a comment wondering about that: // TODO: Should any fast-math-flags be set for the FSUB? Maybe it would be safer for now just to transfer the one flag? |
Just a minor nit: this should be the same constant that the non-strict code also uses. It seems better to create the constant in the same way (code can be shared between both cases).