phoebewang wrote: > ... It has been like that for many years. > Among other things mentioned above, the profit is a reduced chance of > correctness bugs because all the min/max intrinsics treat signed zeros the > same.
So does the unordering signed zero sematics of maxnum/minnum. How does it suddenly become source of correctness bugs? > Given that LLVM currently generates code that actively contradicts its > documentation, I cannot comprehend how you can seriously suggest this. By do nothing, I mean do nothing in changing the code. At the same time, I'm actively suggesting to recover back the documentation regarding that part either in this patch or a revert of the original patch. > 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. At the beginning, I'm talking the problem within the C scope. I extend it because you asked the freedom for other frontends. Then you are opposed to my proposals leveraging C's rules again? > 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... You won't ask the question if you just took a look at the patch that added the builtins. Its rationality comes from #112852, which exactly I'm opposing for here. > The argument that `nsz` is prone to get lost has been rejected by everyone > else. Do you have any evidence for that argument? @nikic explained the intentional part is not a problem. He didn't reject the unintentional part can happen in the wild. BTW, I just saw @arsenm mentioned the problem [here](https://github.com/llvm/llvm-project/pull/166702#issuecomment-3725028269) recently. > 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?) I agree the raito of the unintentional discard is rather small. But the change is in the common path. That says, the effects happen on a `workloads of all frontends * all X86 targets (VRANGE* doesn't help much as I explained above)` basis that using maxnum/minnum. Apparently, it's impossible to watch them all. Not to mention a performance analysis is much harder than a correctness issue. > we're talking about the main LLVM IR, which is shared by a dozen frontends, > most of them out-of-tree. Just a new problem. Besides the fast math flag issue itself, all these frontends 100% suffer performance lose on X86 if they don't change to `minnum + nsz`. And from your prior point, it's not easy to change them all. This seems a bigger problem than I had in mind before. > So if we ignore SNaN... I don't care about SNaN much either. All the proposals is around "what a minnum with +0.0>-0.0 provides but minimumnum not" and above. So let's back to my question again, what's indeed the requirement for changing to the ordering signed zero minnum/maxnum? I have explained "__builtin_elementwise_minnum" is an invalid one. Do you have new evidence? > 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. Sorry, I still don't get a scenario that proves the necessity of the resolution. https://github.com/llvm/llvm-project/pull/172012 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
