[llvm-dev] [754] Fold FP "Op SNaN" to QNaN?

[Kevin Neal via llvm-dev]

Yes, true.

This came up in the context of adding support for the constrained FP intrinsics. These intrinsics all include a metadata argument for specifying how important FP traps are. If traps are “strict” then we can’t fold away any traps. The default FP environment would use “ignore” where there are no traps and folding is fine. I’m working on the “maytrap” case where we can eliminate traps but cannot introduce any new ones. More on constrained intrinsics: https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics


To be clear, are you saying that my interpretation of 754 is correct?

From: Jacob Lifshay <programmerjake at gmail.com>
Sent: Friday, July 09, 2021 2:32 PM
To: Kevin Neal <Kevin.Neal at sas.com>
Cc: LLVM Developers <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [754] Fold FP "Op SNaN" to QNaN?


EXTERNAL
On Fri, Jul 9, 2021, 08:41 Kevin Neal via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
I’m looking at lib/Analysis/InstructionSimplify.cpp where the function propagateNaN() has a comment asking if it should quiet a signaling NaN.

If I understand the IEEE 754-2019 standard correctly: an SNaN shall be converted to a QNaN whenever an “operation” is done. The standard doesn’t say, or I couldn’t find it, exactly _when_ that operation must be done. Which implies that the floating-point operation could be done by the compiler. In which case folding an instruction that has an SNaN operand should result in a QNaN.

That should work just fine, but only when you know that FP exceptions flags are ignored, since the signalling NaN causes the operation to generate the Invalid exception, and a quiet NaN doesn't generally cause exceptions.

Jacob Lifshay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210709/a74f992d/attachment.html>