On Thu, 15 Aug 2024 06:59:53 GMT, Jatin Bhateja <jbhat...@openjdk.org> wrote:
>>> its usage in existing patch is limited to [type >>> comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542) >> >> Ah, that makes sense to me. I took a closer look and I think since the patch >> is creating a `VectorReinterpret` node after unsigned vector nodes, it might >> be able to avoid cases where the type might get filtered/joined, like with >> `PhiNode::Value`. That might lead to errors since >> `empty_type->filter(other_type) == TOP`. It's unfortunate that it's not >> really possible to disambiguate between an empty type and an unsigned range, >> which would allow us to solve this elegantly. > > Hey @jaskarth , Central idea behind introducing VectorReinterpretNode after > unsigned vector IR is to facilitate unboxing-boxing optimization, this > explicit reinterpretation ensures type compatibility between value being > boxed and box type which is always signed vector types. > > As mentioned previously my plan is to address is handle value range related > concerns in a follow up patch along with intrisification and > auto-vectorization of newly created scalar saturating IR, this patch is not > generating scalar IR with newly defined unsigned types. Wonder if it would have been simpler if we added unsigned vector operators like Op_SaturatingUnsignedAddVB etc. We are not adding unsigned data types to Java, only supporting unsigned (saturating) operations on existing signed integral types. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733659843
