aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2023-02-15 08:56:24 -0500
committerSanjay Patel <spatel@rotateright.com>2023-02-15 08:58:07 -0500
commit4c3408697b73fd7c6d58658eeb5b7743cb9fab6c (patch)
tree502e2108bd59e9d6bcafcae4e880981ed7cec3a3 /lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
parent7a282bd2aaa5c1337023578426b15c294eb274bc (diff)
downloadllvm-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/PythonDataObjects.h')
0 files changed, 0 insertions, 0 deletions