[PATCH] D101053: [doc] Clarify constrained fcmps behavior

Thomas Preud'homme via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 22 14:33:59 PDT 2021


thopre added a comment.

In D101053#2709157 <https://reviews.llvm.org/D101053#2709157>, @uweigand wrote:

> The statement is now correct, but it's still not completely clear to me why it is necessary.   **All** floating-point intrinsics may still produce a result in addition to raising an exception (if they do), so the definition of the result is always independent of the question what -if any- exceptions are raised.  Why does this need to be called out here specifically?

Other constrained operation have meaning irregardless of whether a trap is produced for an exception: they limit the sort of optimisation that can be done with FP operation. The distinction between ordered and unordered for constrained fcmps AFAIK only makes sense if no trap happens. I can also add a general reminder that exception does not necessarily implies trap at the beginning of the constrained intrinsics section if it makes more sense but I think we should have something here *as well* because that's where it's important to remember it.

Said another way, realising my mistake that exception != trap I would not change any of the STRICTFP node lowering except for STRICT_FSETCCS.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101053



More information about the llvm-commits mailing list