search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
26.82k stars 10.99k forks source link

rint and nearbyint intrinsic documentation is misleading about exceptions #77561

Open RalfJung opened 6 months ago

RalfJung commented 6 months ago

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 commented 5 months ago

Which PR closed this issue?

dtcxzyw commented 5 months ago

Which PR closed this issue?

Didn't it resolved by https://github.com/llvm/llvm-project/pull/77191?

RalfJung commented 5 months ago

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

dtcxzyw commented 5 months ago

Oh, sorry for my misreading.

arsenm commented 5 months ago

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 commented 5 months ago

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

RalfJung commented 5 months ago

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 commented 5 months ago

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