This is an archive of the discontinued LLVM Phabricator instance.

[PowerPC] Expand constrained ppc_fp128 to i32 conversion
ClosedPublic

Authored by qiucf on Aug 26 2020, 2:35 AM.

Details

Summary

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.

Diff Detail

Event Timeline

qiucf created this revision.Aug 26 2020, 2:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2020, 2:35 AM
qiucf requested review of this revision.Aug 26 2020, 2:35 AM
qiucf updated this revision to Diff 289409.Sep 2 2020, 5:36 AM

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).

qiucf updated this revision to Diff 289874.Sep 4 2020, 12:19 AM
  • Introduce strict version of FADDRTZ
  • Use algorithm similar to expandFP_TO_UINT
uweigand added inline comments.Sep 4 2020, 3:52 AM
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.

qiucf updated this revision to Diff 289978.Sep 4 2020, 9:11 AM
  • 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.

uweigand added inline comments.Sep 4 2020, 9:46 AM
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?

qiucf updated this revision to Diff 289993.Sep 4 2020, 10:33 AM

Only pass nofpexcept flag.

uweigand accepted this revision.Sep 4 2020, 10:45 AM

LGTM now, thanks!

This revision is now accepted and ready to land.Sep 4 2020, 10:45 AM
This revision was automatically updated to reflect the committed changes.