RFR: 8338021: Support saturating vector operators in VectorAPI [v2]

[Sandhya Viswanathan]

On Thu, 15 Aug 2024 06:59:53 GMT, Jatin Bhateja <jbhateja at 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