[llvm] LangRef: rint, nearbyint: mention that default rounding mode is assumed (PR #77191)

[Andy Kaylor via llvm-commits]

================
@@ -15751,7 +15751,9 @@ Semantics:
 """"""""""
 
 This function returns the same values as the libm ``rint`` functions
-would, and handles error conditions in the same way.
+would, and handles error conditions in the same way. The rounding mode
----------------
andykaylor wrote:

> This isn't how they're handled today, but I have a model of how to support FP exceptions better in LLVM IR, which draws from C's FENV_ACCESS rules. In non-exception-aware code, the state of the FP exception bits would be unspecified (probably `poison`) at any point in time, whereas exception-aware code would have the bits set as specified by IEEE 754. This model would largely reuse the existing intrinsics for operations (and with a few other changes I think could eliminate the need for duplicated constrained intrinsic versions), so I've already largely mentally mapped every such intrinsic to the corresponding IEEE 754 operation, even in cases where two operations would have the same effect but for exception handling, which technically requires the experimental constrained intrinsics at the moment.

I'm not clear how you intend to achieve such a thing, but it sounds interesting. How would we distinguish "exception-aware code" from "non-exception-aware code"?

I think the main reason for LLVM's non-handling of exceptions is that assuming instructions don't have side-effect frees us to do a lot of code motion without having to worry about side-effects. The constrained intrinsics were introduced, in part, as a way to indicate when we needed side-effects to be respected. I'd be all for eliminating the redundant intrinsics, but we'd need a way to ensure that all code which operates on FP instructions and calls would handle the case when side-effects needed to be enforced.

https://github.com/llvm/llvm-project/pull/77191