[PATCH] D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

I've been thinking about the getStrictFPOperationAction issue.  I believe this function makes no sense at all and really should go away.  Instead, the strict opcodes should use their own operation actions just like everything else.  In current code, those should now be set up in a reasonable manner: they all default to Expand, unless the target overrides them (to whatever makes sense).

If the operation action is anything but Expand, I believe it should simply be respected as-is (i.e. Legal stays until ISel, Custom calls the target hook, Promote -if ever used- should be implemented in common code in a way that preserves strictness, and LibCall should emit a library call - possibly a strict version if necessary).

Now, if the operation action of a strict FP operation is Expand, common code should **try** to implement an expansion rule if possible in a way that preserves strictness.  If that is **not** possible, then and only then should we think about falling back to a non-strict implementation.   That fallback (and only that fallback) now should look at the operation action of the non-strict equivalent.  If that is anything but Legal, then the expansion logic should replace the strict node with a non-strict node and push that non-strict node back to the legalizer to handle it in whatever way is indicated by its operation action.  If the operation action is Legal, then we can leave the strict node in and mutate it to the non-strict node only shortly before ISel as is done today.

As to when an expansion is possible in a way that preserves strictness, and when to fall back to the non-strict equivalent:  For a vector op, I believe it always makes sense to expand a strict vector op by scalarizing it to strict component ops.  (Except, possibly, if that scalar op would itself fall back to its non-strict eqiuvalent -- then we might as well do the fallback on the vector type.)  For scalar ops, for some it could be possible to expand them while respecting strictness, e.g. for some of the fp-to-sint cases above.  That can be decided on a case-by-case basis.  If at the end of ExpandNode we haven't found a way to expand a strict node, we can to the fallback then.

Does this make sense?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63782