[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