phoebewang wrote: > I'm not sure what you mean by this. The only open question around signed zero > is whether the operation "minnum (2008-style) with signed zero ordering" > _exists_, right? The existence of an operation doesn't create a cost for > people not using it (apart from general LLVM maintenance costs ofc).
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. > Or is your main objection not the existence of that operation, but the fact > that old bitcode and old frontends that use `minnum` will be implicitly > re-interpreted as using the "ordered signed zero" variant? Could the bitcode > import mechanism realize that it is converting LLVM 21 bitcode to 22 and then > implicitly add `nsz`? And similarly the builder APIs used by old frontends > could add `nsz` and new APIs could add `minnum` without `nsz`? Not sure if > there is precedent for that or if it's worth the effort though -- ultimately, > the worst thing that can happen to old bitcode and old frontends is worse > performance. This is basicly impossible and far less feasible than what I proposed adding `_ieee` intrinsics instead. > Yes, someone will have to do the implementation work for a minnum variant > that guarantees ordering of signed zeros. But if there's demand for that > operation (it apparently already exists in clang) and given that you don't > have to be the one doing that work, that seems fine? 1. I don't see a concrete demand so far. There's demonstration `maxnum(x, 0.0)` doesn't necessarily have cost on X86, but lacks details where it's transferred from. And most importantly, I doubt the rationality transferring any instructions to `maxnum(x, 0.0)` considering the sNaN non-determinism. Then I was told it's just an offhand idea; 2. It is not just implementation work. It bloats the code for `Oz` and soft-float platform, which might be unacceptable by such users; 3. Last but not least, I'm one of the maintainer of X86 backend. I have criteria to accept patches or not. It simply based on either a patch do more good than harm to X86, or there's no good nor harm to X86 but important to others. Apparently, from what I have learnt so far, the potential patches don't meet the criteria. I'm actively blocking here in case people waste time on it. I was surprised what I'm doing is just wasting people's time; > Is there a reason to think that this is more likely than bugs caused by > minnum confusingly having a different signed-zero treatment than the other, > similar operations? I don't think so. I'm not sure what's your mean here. Bugs are bugs. The change from inherent feature to external flags is a degradation in the reliability, which is always a valid concern. > That seems unlikely. It can be discussed if/when such a transformation > actually gets proposed. "Someone could maybe theoretically hold it the wrong > way" is IMO a bad argument; almost every feature can be misused after all. But there's a better way to prevent it. Like what I proposed, if we add `_ieee` intrinsics and used for optimization, we can easily find the problem. Because we can make them legal only when we have native instruction support. Then we will get error when it's misused on unspported targets. > The pros are: it reduces confusion and increases maintainability by having a > reasonably understandable, coherent set of operations for min/max on floats, > organized along the orthogonal axes of "NaN treatment" and "signed zero > treatment". Also it provides enough flexibility that it gained consensus of > most people involved in this discussion. As Nikita said, the actual semantics > barely matter, what matters is getting _something_ documented so that the > work of fixing the implementation can begin. Is your remaining concern > important enough to keep blocking that work? A shared IR, with shared > semantics, is always a compromise; in this case, the compromise manifests in > the form of having a wider range of operations than any one person actually > needs, to ensure that it covers what most people need. We all have interests based on what we are working. I have explained the reasons I block it. It can be proved wrong or changed with more information. But at this time, I'm opposed to the ordering zero change. https://github.com/llvm/llvm-project/pull/172012 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
