[llvm] LangRef: Clarify behaviors of nsz in fast math flag (PR #137567)

[Andy Kaylor via llvm-commits]

andykaylor wrote:

> Calling this semantics is too strong; it's a relaxation permitted by the standard. The superior QoI that it seems just about every ISA implemented is to properly order -0 < +0, and this is the required behavior for both minimum and minimumNumber in the 2019 version. This is a semantic relaxation, and as the one place with a standard has a fuzzy signed zero handling I think the goal should be to define NSZ around this. I don't see how it's useful to permit flipping the sign out of nothing

I'm not claiming that it's useful to do that. I'd be surprised if that ever happened. What I'm saying is that I don't understand why we need the restriction in the definition to say that it can't happen. If it's not useful, it won't happen. If someone somehow came up with a scenario where it was useful (perhaps as part of a transformation involving a chain of instructions with a min/max intrinsic in the middle), we might end up revisiting this discussion.

I agree that further proliferation of the min/max intrinsics is a bad idea, but I don't like the idea of changing the meaning of `nsz` to make one of them fit a desired characteristic.

You want to `nsz llvm.minnum` to be able to return either +0 or -0 if the arguments are one of each. I think the current definition allows that. You want to restrict it so that it can't return `-0` if both arguments are `+0`. I don't think that's going to happen, but I do think the current definition of `nsz` allows it.

It sounds to me like the problem here is that rather than using a fast-math flag because the user requested the associated fast-math property to be enabled, you want to introduce a fast-math flag on a specific operation to get specific behavior from an intrinsic. That sounds to me an awful lot like the x86 backend wanting to interpret the `reassoc` flag when attached to `llvm.vector.reduce.fadd` to require a specific re-ordering.

https://github.com/llvm/llvm-project/pull/137567