llvm / llvm/llvm-project

[CodeGen] Remove `FMINNUM_IEEE` and `FMAXNUM_IEEE`

Open
#178,094 6 comments 0 reactions 0 assignees View on GitHub
llvm:codegen
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.