| Issue |
178094
|
| Summary |
[CodeGen] Remove `FMINNUM_IEEE` and `FMAXNUM_IEEE`
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
valadaptive
|
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`.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
