[llvm-dev] [cfe-dev] Intrinsic llvm::isnan

[James Y Knight via llvm-dev]

On Tue, Aug 24, 2021 at 1:53 PM Roman Lebedev via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Regardless of everything, i would like to see a patch that restores
> the -ffast-math handling, and *then* the RFC on what the is-nan check
> should do when -ffast-math is present.
> It is more than possible that the RFC will succeed,
> but i don't think a change like that should happen the way it did.


I find the rationale to be convincing, as to the need for a change. But,
the scope of the proposal is too narrow. We cannot discuss fast-math
semantics changes *only* for "isnan", it needs to be in the context of the
desired behavior for all operations -- the RFC should cover the entire set
of changes we want to eventually make, even if isnan is the only thing
implemented so far. Discussing this greater scope could result in a
different desired implementation, rather than simply adding "llvm.isnan"
intrinsic.

Yet, even with that expanded scope, the two halves of the proposal are
still going to be closely linked, so I suspect it still makes sense to
discuss both the strict-fp and fast-math changes in a single RFC.

Anyhow, for the fast-math section, I believe the proposed semantics ought
to be:
  The -ffinite-math-only and -fno-signed-zeros options do not impact the
ability to accurately load, store, copy, or pass or return such values from
general function calls. They also do not impact any of the
"non-computational" and "quiet-computational" IEEE-754 operations, which
includes classification functions (fpclassify, signbit, isinf/isnan/etc),
sign-modification (copysign, fabs, and negation `-(x)`), as well as
the totalorder and totalordermag functions. Those correctly handle NaN,
Inf, and signed zeros even when the flags are in effect. These flags
*do* affect
the behavior of other expressions and math standard-library calls, as well
as comparison operations.

I would not expect this to have an actual negative impact on the
performance benefit of those flags, since the optimization benefits mainly
arise from comparisons and the general computation instructions which are
unchanged.


> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949 was mentioned as
> motivational, but i don't see any resolution there,
> it's not even in "confirmed" state.


I agree, this is not at all clear evidence as to GCC's position on the
matter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210824/6bf95a8f/attachment.html>