RalfJung wrote: > You are correct. _ieee probably not a good name. I borrowed it from the > backend notes FMINNUM_IEEE. Because the meaning is identical to the > defination > [here](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/CodeGen/ISDOpcodes.h#L1074).
Thanks for that link. So that sounds exactly like `minnum` from this PR? > No, I'm not proposing to replace minnum with minnum_ieee, despite it's > possible. ... now I am totally confused. What are you proposing then? Just one sentence above you provided a link which seems to say that `minnum_ieee` is exactly like `minnum` in this PR. > Since we query HW's capability before emitting minnum_ieee and minnumnum, It is completely inacceptable to ask frontends to do that. This is the kind of work backends should do. This is not an "llvm.x86.something" vendor intrinsic. There is no other "portable" intrinsic that asks frontends to first query HW capabilities, is there? You are fundamentally changing how frontends are supposed to use LLVM IR, in a way that makes LLVM a lot worse to use. You are also asking for code duplication and bugs, since inevitably some frontends will get this check wrong as not all frontends have hardware experts for all backends at hand. We're not talking about some Codegen IR here. We're talking about the surface IR shared by dozens of frontends, most of them out-of-tree. > If any optimizations generate minnum_ieee on unsupported targets, we will > know through compile failures. There cannot be such a thing as an "unsupported target" for a portable LLVM IR intrinsic. That would be an LLVM bug. Or may you mean the Codegen opcodes? But those are entirely irrelevant here, we're talking about the main LLVM IR. > minnum_ieee provides the best coverage for any requirement and lest efforts > in the implementation. Your `minnum_ieee` is just a different name for what this PR calls `minnum`. So the coverage provided and backend implementation effort is exactly the same. > To be fair, can you explain where the requirement from? @nikic 's summary > just talked from symmetric aspect. It seems you are the one who think there > are concrete use scenarios. https://clang.llvm.org/docs/LanguageExtensions.html has been mentioned above, search for "__builtin_elementwise_min" on that page. And for Rust, it's simply not clear yet which semantics will be picked. Having LLVM provide a reasonable matrix of options allows frontends to make the choice that works best for their tradeoffs. But also, just look at the table we'd get under your proposal (I am guessing here what your proposal is since you didn't fully explain it in the previous post -- maybe you should make a PR yourself so we know what you are even suggesting): | | `-0.0 < +0.0` | Signed zero order is non-det | | ----------- | -------------- | ------------------------- | | Return NaN if either argument is NaN | `minimum` | `minimum nsz` | | Return other argument if one argument is NaN (QNaN or SNaN) | `minimum_num` | `minimum_num nsz` | | Return other argument if one argument is QNaN; Return other argument or NaN if one argument is SNaN | `minnum_ieee` | `minnum` That's clearly not a great design, is it? The last row completely breaks the pattern. Even if we just remove `minnum_ieee` and not have that operation at all, the pattern is still broken. https://github.com/llvm/llvm-project/pull/172012 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
