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

[Jatin Bhateja]

On Thu, 15 Aug 2024 03:01:00 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> @jaskarth , its usage in existing patch is limited to [type comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542). 
>> 
>> My plan is to address intrinsification of new core lib APIs, associated value range folding optimization (since unsigned numbers have different value range of [0, MAX_VALUE) vs signed [-MIN_VALUE/2, +MAX_VALUE/2) numbers) and auto-vectorization in a follow up patch.
>> 
>> **Notes on C2 type system:**  
>> Unlike Type::FLOAT, integral type ranges are specified using _lo and _hi value range, these ranges are pruned using flow functions associated with each operation IR.  Constraining the value ranges allows logic pruning, e.g.  in1[TypeInt]  & 0x7FFFFFFF  will chop off -ve values ranges from in1,  thus a constrol structure like . `if (in1 < 0) { true_path ; } else { false_path; } `  which uses in1 as a flow condition will sweepout the true path.
>> 
>> C2 type system only maintains value ranges for integral types i.e. long and int, any sub-word type which as per JVM specification has an int storage "word" only constrains the value range of TypeInt.  
>> 
>> A type which represent a constant value has same _hi and _lo value.
>> 
>> Floating point types Type::FLOAT / DOUBLE cannot maintain upper  / lower value ranges due to rounding constraints.
>> Thus C2 type system maintains a separate type TypeF and TypeD which are singletons and represent a constant value.
>
>> 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.

@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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1718044262