aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
diff options
context:
space:
mode:
authorRalf Jung <post@ralfj.de>2024-10-11 16:01:07 +0200
committerGitHub <noreply@github.com>2024-10-11 18:01:07 +0400
commita8a66245954f8ef079708d314f0059d6c3e07b28 (patch)
treee0d0c788e56dbe9b0bbd4ac59bf5bf79d4e17dbb /llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
parent4b3f251bada55cfc20a2c72321fa0bbfd7a759d5 (diff)
downloadllvm-a8a66245954f8ef079708d314f0059d6c3e07b28.zip
llvm-a8a66245954f8ef079708d314f0059d6c3e07b28.tar.gz
llvm-a8a66245954f8ef079708d314f0059d6c3e07b28.tar.bz2
[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).
Diffstat (limited to 'llvm/lib/Analysis/ModuleSummaryAnalysis.cpp')
0 files changed, 0 insertions, 0 deletions