On Thu, 15 Aug 2024 03:01:00 GMT, Jasmine Karthikeyan <jkarthike...@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
