[CodeGen] Remove `FMINNUM_IEEE` and `FMAXNUM_IEEE`
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
Now that #172012 is merged and the behavior of `minnum`/`maxnum` has been clarified, we should be able to remove the `FMINNUM_IEEE` and `FMAXNUM_IEEE` opcodes and replace them with `FMINNUM`/`FMAXNUM`. They are basically the same as `FMINNUM_IEEE` and `FMAXNUM_IEEE` now, except they're allowed to nondeterministically return either "a NaN" *or* the numeric operand if a sNaN is passed.
AFAIK (correct me if I'm wrong), we've never been able to promise anything about particular NaN bit patterns, so we can't guarantee that 1) a particular opcode behaves deterministically with regards to a qNaN vs. an sNaN input, or 2) a particular opcode outputs a qNaN specifically. I *think* this applies even to SelectionDAG.
I tried starting in on this myself, but there seem to be a number of optimization differences between the two. I'm not entirely sure which optimizations are legal or not, since sNaN behavior is now specified to be nondeterminstic, and I think some existing optimizations are unsound.
I'm also a bit lost as to how and where `FMINNUM`/`FMAXNUM` get transformed into `FMINNUM_IEEE` and `FMAXNUM_IEEE`. The backends are a bit haphazard about which types support the IEEE vs. non-IEEE versions; some support both, some arbitrarily support one but not the other.
I think the best course of action is actually to first remove `FMINNUM`/`FMAXNUM` and use the IEEE versions instead, which should get rid of any unsound optimizations that rely on *all* NaNs being treated the same (or assume it's OK to lower to an operation that doesn't handle signed zero, such as a libcall). After that, we can simply rename `FMINNUM_IEEE` and `FMAXNUM_IEEE` to `FMINNUM` and `FMAXNUM`.
Contributor guide
Research direction
Start with the behavior clarified by #172012, then trace how FMINNUM/FMAXNUM are transformed into their IEEE variants across CodeGen, backends, and SelectionDAG. Determine which optimization differences and NaN or signed-zero assumptions are legal; done means the opcode transition and final renaming are consistently applied.
Written by the indexing model from the issue text.
Assessment
- Domain
- compilers
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100