ebevhan added a comment. In D82663#2153834 <https://reviews.llvm.org/D82663#2153834>, @rjmccall wrote:
> I don't understand. The problem statement as I understood it is that using > unsigned intrinsics to do unsigned-with-padding operations is leading to poor > code-gen, so you want to start using signed intrinsics, which you can safely > do because unsigned-with-padding types are intended to be exactly signed > types with a dynamic range restriction to non-negative values. The result of > that operation is still logically an unsigned-with-padding value; there's no > need to return back a modified semantic that says that the result is really a > signed value because it's *not* really a signed value, you're just computing > it a different way. I also don't understand why you think need a modified > semantics value in the first place as opposed to just using a more complex > condition when deciding which intrinsics to use. Well, it's not just about intrinsics. For saturating operations, the common semantic width is currently narrowed by one bit to get the correct saturating behavior on the operation afterwards. This affects the conversion to the common semantic, since the type will be one bit narrower. But I realize now that it probably doesn't matter if we simply don't do that narrowing when constructing the common semantic. That way it will always have the right width and we can just do as you say and select the right intrinsic based on the padding bit information. Alright, that should probably work. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82663/new/ https://reviews.llvm.org/D82663 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
