[PATCH] D81537: [PowerPC] Support constrained fp operation for scalar fptosi/fptoui

Thu Jun 25 09:07:40 PDT 2020

uweigand added inline comments.

================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:582
+    if (Subtarget.hasSPE()) {
+      setOperationAction(ISD::STRICT_FP_TO_UINT, MVT::i32, Legal);
       setOperationAction(ISD::FP_TO_UINT, MVT::i32, Legal);
----------------
uweigand wrote:
> jhibbits wrote:
> > nemanjai wrote:
> > > steven.zhang wrote:
> > > > Don’t do this for spe target and remove the test for spe. Sorry about the back and forth.
> > > I would defer to @jhibbits @chmeee (not sure which of Justin's ID's is active) regarding SPE bits.
> > What are the semantic differences between STRICT_FP_TO_UINT and FP_TO_UINT?  EFDCTUIZ/EFSCTUIZ and their signed counterparts, which we currently use for the FP_TO_{U,S}INT, saturate if they can't be represented as a 32-bit integer, and round toward zero always (the non-Z variants round via the current rounding mode).
> FP_TO_UINT assumes the current rounding mode is default, and exception conditions can be ignored.  With STRICT_FP_TO_UINT those assumptions no longer apply, so it would appear that those instructions you mention should not be used there.
Ah -- my last comment was incorrect, sorry for any confusion.

STRICT_FP_TO_UINT/SINT are in fact an exception to most "STRICT" operations in that they do **not** use the current rounding mode, but always round towards zero.  (Following the C standard as well as the LLVM IR specification.)

So for these operations the only difference between strict and non-strict variants is whether exception conditions can be ignored or not.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81537/new/

https://reviews.llvm.org/D81537