RalfJung wrote: > So you should also object to this patch, because it nearly clones > minnum/maxnum from minimumnum/maximumnum with the only sNaN difference.
What are you talking about? Your reply seems to have nothing to do with the paragraph you quoted. Nobody talked about cloning anything. The argument was that we shouldn't have intrinsics which fail on some targets. > Did you forget minimumnum and maximumnum when saying uniform? I asked more > than once, but nobody explained why the optimizaiton must use minnum/maxnum. > Yes, minimumnum/maximumnum has cost to quiet sNaN. But then, why the sNaN > just be ignored by the optimizaiton using minnum/maxnum? Which optimization...?!? If you still refer to Nikita's earlier comment, then -- haven't you read his later comments? It's not about optimizations. > Not sure if we misunderstood each other. What I forbid to use? You want to prevent `minnum` with ordered zeros from existing. Don't you? That's what the discussion has been about. > Frontends do many target-spcific things, typically the ABI or FP types target > supported. So it's not a problem to define and query if signed zeros and > which version IEEE2008 vs. IEEE2019 sNaN supported, and lower to minnum, > minimumnum, minnum_ieee accordingly based on the language requirments. That sounds terrible. It makes life harder for frontends for no good reasons. It's much better if the frontend can convey the language requirements to LLVM and then LLVM generates code according to those requirements. That's how things work usually in LLVM. > Yes, I'm saying the risks. Why do we take the risks we shouldn't have to? Using attributes like this is a common pattern and seems to work very well. You have not explained why there is a relevant risk here, given that this work very well for `getelementptr` and `add` and many other operations. And the reasons for wanting to have this degree of freedom have been given above multiple times. Unfortunately you didn't reply to the request for clarification about your counterproposal. Though you did mention having the frontend query backend info to figure out which intrinsic to use, and that sounds like a really bad idea. It pushes work that LLVM should be dong into frontends. https://github.com/llvm/llvm-project/pull/172012 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
