[clang] [llvm] [LangRef] Clarify specification for float min/max operations (PR #172012)

[Phoebe Wang via cfe-commits]

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