rint and nearbyint intrinsic documentation is misleading about exceptions

[RalfJung]

The rint intrinsic makes this statement about FP exceptions:

It may raise an inexact floating-point exception if the operand isn’t an integer.

nearbyint differs from rint by not having that statement.

However, this is misleading, since LLVM also documents "the default LLVM floating-point environment assumes that traps are disabled and status flags are not observable". This means that whether or not rint raises an exception is assumed to be un-observable, and LLVM will freely reorder rint with other operations that might alter FP exception flags. Effectively, rint and nearbyint provide equivalent semantics (as least that's how LLVM frontends should treat the situation), and anyone relying on rint doing anything with exceptions will be disappointed eventually.

It would probably be better to remove any mention of exceptions in the rint and nearbyint docs, and possibly to merge those intrinsics. People relying on exception behavior need to use the constrained intrinsics.

[RalfJung]

Which PR closed this issue?

[dtcxzyw]

Which PR closed this issue?

Didn't it resolved by #77191?

[RalfJung]

No, that did not change the discussion of exceptions, only of rounding modes. The issue should be reopened.

[dtcxzyw]

Oh, sorry for my misreading.

[arsenm]

This is an unfortunate leftover from before there was a design for strictfp support. We now have 3 intrinsic that mean the same thing. nearbyint, rint and roundeven all do the same thing. We should probably drop llvm.nearbyint and llvm.rint, and auto upgrade them to roundeven (but this would potentially not be worth the asymmetry with the constrained intrinsics)

[RalfJung]

That still seems preferable over the confusion caused when frontends think there is a meaningful difference between these intrinsics.

[RalfJung]

That said, when Rust tried to use roundeven we ran into issues since it is less widely supported by platforms' libm than the alternatives.

[arsenm]

That said, when Rust tried to use roundeven we ran into issues since it is less widely supported by platforms' libm than the alternatives.

That's a lowering issue. We should just start remapping the calls to whatever call exists instead of expecting exact match like happens now