Page MenuHomePhabricator

[PowerPC] Respect rounding mode in the back end
ClosedPublic

Authored by nemanjai on Oct 8 2021, 8:57 AM.

Details

Reviewers
rzurob
bmahjour
qiucf
Group Reviewers
Restricted Project
Commits
rG5840f7197d05: [PowerPC] Respect rounding mode in the back end
Summary

Currently, the floating point instructions that depend on rounding mode are correctly marked in the PPC back end with an implicit use of the RM register. Similarly, instructions that explicitly define the register are marked with an implicit def of the same register. So for the most part, RM-using code won't be moved across RM-setting instructions.

However, calls are not marked as RM-setting instructions so code can be moved across calls. This is generally desired, but so is the ability to turn off this behaviour with an appropriate option - and -frounding-math really should be that option.

This patch provides a set of call instructions (for direct and indirect calls) that are marked with an implicit def of the RM register. These will be used for calls that are marked with the strictfp attribute.

Diff Detail

Event Timeline

nemanjai created this revision.Oct 8 2021, 8:57 AM
nemanjai requested review of this revision.Oct 8 2021, 8:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 8 2021, 8:57 AM
jsji added a reviewer: qiucf.Oct 13 2021, 7:11 AM
rzurob accepted this revision.Oct 13 2021, 7:49 AM

LGTM

This revision is now accepted and ready to land.Oct 13 2021, 7:49 AM
qiucf added a comment.Oct 13 2021, 7:58 AM

Thanks for fixing this!

I guess the reason to restrict them only undef strict-fp is performance? Since FPSCR is not modeled yet, if so, we may need to re-define all float instructions like this patch when implementing FPSCR model?

llvm/lib/Target/PowerPC/PPCISelLowering.cpp
5221

Better to move this into a static function?

llvm/lib/Target/PowerPC/PPCInstr64Bit.td
181

Can they be implemented through multiclass/defm?

Thanks for fixing this!

I guess the reason to restrict them only undef strict-fp is performance?

Right, preventing optimization around calls due to rounding mode without -frounding-math would be unnecessarily restrictive for most compilations.

Since FPSCR is not modeled yet, if so, we may need to re-define all float instructions like this patch when implementing FPSCR model?

There are only a handful of instructions that actually set the rounding mode (or other fields in the FPSCR) and they should be defined as such. The instructions that just use the rounding mode already have it as an implicit use. While there may be other, more esoteric interactions with the FPSCR, I believe that handling the rounding mode and exceptions correctly should suffice for a vast majority of uses. And I believe that we are pretty close to all of that working correctly.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp
5221

I don't have a particularly strong opinion on this since we are already in a static function and the code would read exactly the same. I already separated it into code that computes the node to use and then code that updates the opcode for strictfp, so it can very easily be two separate functions.

If you have a preference for moving it out, please let me know and I'll update it.

llvm/lib/Target/PowerPC/PPCInstr64Bit.td
181

Absolutely, but I don't think we'd make it any more readable or concise since we'd need 4 new multiclasses for:

IForm
IForm_and_DForm_4_zero
XLForm_2_ext
XLForm_2_ext_and_DSForm_1
nemanjai added inline comments.Oct 19 2021, 2:28 AM
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
5221

@qiucf I am waiting to hear from you whether you insist on this change or if you're OK with my rationale above.

qiucf accepted this revision as: qiucf.Oct 19 2021, 5:54 AM
qiucf added inline comments.
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
5221

Ah sorry. I meant to have no objections. This looks good to me. Thanks!

This revision was landed with ongoing or failed builds.Wed, Nov 10, 6:20 AM
This revision was automatically updated to reflect the committed changes.