Open 10db7940-d837-414a-8e65-1a0425eb097b opened 3 years ago
I don't think minimumNumber and minNum are the same thing in the IEEE spec I dug out IEEE754 2008 and it turns out that minNum was removed and replaced with minimumNumber, which (for our purposes) essentially is the same function as minNum, but with -0 treated as less than +0.
(I had been confused, and thought that it was just the LLVM docs abbreviating minimumNumber as minNum, apologies)
Does the IEEE description for minimumNumber match the behavior of llvm.minimum? llvm.minimum propagates NaN, and minimumNumber returns the other arg if one is NaN (same as the way llvm.minnum does).
For clarity: in addition to minimumNumber
, IEEE754 2019 defines a minimum
function that does behaves identically to llvm.minimum
. (It defines 2 max functions and 2 min functions)
For Rust this wouldn't be usable here, as we've already guaranteed the that f32::min
will return the other argument when one argument is a NaN.
Is there a way to read the updated standard without going through some kind of login/paywall? There are various methods you can use to access research papers, academic publications, etc. Your local library may be one, although there may be certain websites that fulfill similar roles without requiring logins, which may be convenient during lockdown.
This patch was supposed to update the LangRef: https://reviews.llvm.org/D67507 ...but it's gone nowhere for over a year.
Is there a way to read the updated standard without going through some kind of login/paywall?
Does the IEEE description for minimumNumber match the behavior of llvm.minimum? I don't think minimumNumber and minNum are the same thing in the IEEE spec.
Extended Description
Note: this applies for both
llvm.minnum
andllvm.maxnum
, although for the most part I'm just going to talk about the min case — both have this bug, though.The documentation for
llvm.minnum.*
says:In Rust (https://github.com/rust-lang/rust/issues/83984) we use
llvm.minnum
andllvm.maxnum
for our normal float min/max operations, and would like these to be compliant with the IEEE-754 functions, with respect to -0.0.Alternatively, if this cannot be fixed, it would be nice to have a pair of set of min/max functions that do implement the IEEE754 semantics (and also probably update the documentation to say that the handling of -0.0 differs from IEEE-754 as well)
P.S. We cannot use
llvm.minimum
— While it would handle -0.0 properly, they handle NaNs completely differently, and we've documented the current "returns non-NaN for NaN input" behaviorP.P.S. I had no clue what component to put this under, sorry.