[all-commits] [llvm/llvm-project] a8a662: [IR] LangRef: state explicitly that floats general...
Ralf Jung via All-commits
all-commits at lists.llvm.org
Fri Oct 11 07:01:29 PDT 2024
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: a8a66245954f8ef079708d314f0059d6c3e07b28
https://github.com/llvm/llvm-project/commit/a8a66245954f8ef079708d314f0059d6c3e07b28
Author: Ralf Jung <post at ralfj.de>
Date: 2024-10-11 (Fri, 11 Oct 2024)
Changed paths:
M llvm/docs/LangRef.rst
Log Message:
-----------
[IR] LangRef: state explicitly that floats generally behave according to IEEE-754 (#102140)
Fixes https://github.com/llvm/llvm-project/issues/60942: IEEE semantics
is likely what many frontends want (it definitely is what Rust wants),
and it is what LLVM passes already assume when they use APFloat to
propagate float operations.
This does not reflect what happens on x87, but what happens there is
just plain unsound (https://github.com/llvm/llvm-project/issues/89885,
https://github.com/llvm/llvm-project/issues/44218); there is no coherent
specification that will describe this behavior correctly -- the backend
in combination with standard LLVM passes is just fundamentally buggy in
a hard-to-fix-way.
There's also the questions around flushing subnormals to zero, but [this
discussion](https://discourse.llvm.org/t/questions-about-llvm-canonicalize/79378)
seems to indicate a general stance of: this is specific non-standard
hardware behavior, and generally needs LLVM to be told that basic float
ops do not return the standard result. Just naively running
LLVM-compiled code on hardware configured to flush subnormals will lead
to #89885-like issues.
AFAIK this is also what Alive2 implements (@nunoplopes please correct me
if I am wrong).
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list