diff options
| author | Sanjay Patel <spatel@rotateright.com> | 2023-02-15 08:56:24 -0500 |
|---|---|---|
| committer | Sanjay Patel <spatel@rotateright.com> | 2023-02-15 08:58:07 -0500 |
| commit | 4c3408697b73fd7c6d58658eeb5b7743cb9fab6c (patch) | |
| tree | 502e2108bd59e9d6bcafcae4e880981ed7cec3a3 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h | |
| parent | 7a282bd2aaa5c1337023578426b15c294eb274bc (diff) | |
| download | llvm-4c3408697b73fd7c6d58658eeb5b7743cb9fab6c.zip llvm-4c3408697b73fd7c6d58658eeb5b7743cb9fab6c.tar.gz llvm-4c3408697b73fd7c6d58658eeb5b7743cb9fab6c.tar.bz2 | |
[LangRef] improve documentation of SNaN in the default FP environment
Make it explicit that SNaN is not handled differently than
QNaN in the LLVM default floating-point environment.
Note that an IEEE-754-compliant model disallows transforms
like "X * 1.0 -> X". That is because math operations are
expected to convert SNaN to QNaN (set the signaling bit).
But LLVM has had those kinds of transforms from the beginning:
https://alive2.llvm.org/ce/z/igb55y
We should be IEEE-754-compliant under strict-FP (the logic is
implemented with a helper named canIgnoreSNaN()), but I don't
think there is any demand to do that with default optimization.
See issue #43070 for earlier draft/discussion about this change.
Differential Revision: https://reviews.llvm.org/D143074
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h')
0 files changed, 0 insertions, 0 deletions
