RalfJung wrote: Deterministic SNaN behavior is way outside the scope of this PR. SNaN is consistently ignored across LLVM IR. It has been like that for many years. This PR changes nothing in SNaN treatment, so the situation at least does not get worse. *Please* do not block the resolution of other, non-SNaN-related min/max issues on figuring out the huge, wide-open, and mostly orthogonal design space of how to deal with SNaN. You are doing the equivalent of "before you can repaint this room, you must first redo the roof".
> Do nothing. Given that LLVM currently generates code that actively contradicts its documentation, I cannot comprehend how you can seriously suggest this. > "__builtin_elementwise_minnum" probably unrelated here. The current solution > makes sNaN non-deterministic. To strict follow IEEE 754-2008, we need the > full support I'll propose in phase 2. That's not correct. clang is a C compiler and therefore SNaN is implicitly unsupported, as per the C standard. The docs of a C compiler generally implicitly only refer to QNaNs. OTOH, those docs very clearly ask for "minnum but with signed zero ordering". How convenient of you to discard the exact evidence you asked for... > Phase 2 So if we ignore SNaN -- which we should, because *this PR does not change anything about SNaN* and therefore it makes no sense at all to criticize this PR for anything SNaN-related -- then I think this is entirely identical to what this PR does, except that the table looks the way I posted above rather than being nice and symmetric? > We all have our criteria to judge whether one thing is permitted or not. For > backend, we are keen on haggling minor performance differentiation, often > deep diving to 1-2 cycles or 1/2-1/3 throughput differences of one > instruction. So performance lost, no matter how corner it applies (bitcode > user), how rare chance it happens (nzs discard), it is a red flag if the > profit is 0. Performance is lost *all the time*. When some optimization heuristic gets changed, it benefits most programs but for some things get worse. Completely hypothetical scenarios of performance loss are therefore not productive. I think you are exaggerating both how likely this is to happen, and how bad it would be. (Obviously you have tests to catch all the obvious cases, right?) https://github.com/llvm/llvm-project/pull/172012 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
