RalfJung wrote: > No, I'm saying from an end (C language) to end (codegen) perspective, it just > happens to match with IEEE2008 as well. I think > [here](https://discourse.llvm.org/t/rfc-a-consistent-set-of-semantics-for-the-floating-point-minimum-and-maximum-operations/89006/60) > is a good summary. In a word, the consumer doesn't need it and the producer > doesn't guarantee it. As a middlewire connecting both, forcing the zero > ordering to it is just redundant.
You seem to be confirming what I am saying -- you are fundamentally objecting to the IR even having this operation. Neither C nor IEEE mandate signed zero ordering for `minnum`, that is true. But C is not the only language in the world. Some LLVM frontends may still want to have a version of this operation where the ordering is guaranteed. After all, neither C nor IEEE have versions of `minimum`/`minimumnum` (the 2019 operations) *without* signed zero ordering, and yet LLVM provides them, because it could be useful for frontends such as clang with a (non-standard) flag to ignore signed zero ordering. Similarly, clang also has an operation that is documented as "Follows IEEE 754-2008 semantics (minNum) with +0.0>-0.0". I don't know who is "producer" and "consumer" for you, but there are frontends asking for it, and it is clearly feasible for backends to implement it (not using a libcall, but intrinsics don't *have* to be compiled to libcalls). You personally seem to have no need for this operation, which is fine, but why do you want to forbid others from having it? > It is not just implementation work. It bloats the code for Oz and soft-float > platform, which might be unacceptable by such users; It doesn't bloat anything. A frontend that doesn't want signed zero ordering just sets `nsz` and there's no bloat. A frontend that wants signed zero ordering can omit the `nsz`, and then the extra code isn't bloat, it is basic functionality demanded by the frontend. It is not your call to decide that something is unacceptable for all frontends. It is up to the frontend to decide what is acceptable for their users; LLVM IR should just provide the means of expressing those trade-offs. You arguments sound as-if this PR would *force* frontends to use signed zero ordering. That's not the case, so I don't understand why you are arguing as if it was the case. > The change from inherent feature to external flags is a degradation in the > reliability, which is always a valid concern. What do you mean by "external flags"? You mean `nsz`? It is very common for LLVM to encode crucial information with such flags, e.g. `getelementptr inbounds` or `add nsw`. That does not seem to be a problem in practice, it is very reliable. Why is this `nsz` information so much more important that this established level of reliability does not suffice? https://github.com/llvm/llvm-project/pull/172012 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
