RFR: 8370914: C2: Reimplement Type::join [v7]

[Quan Anh Mai]

On Wed, 7 Jan 2026 15:19:04 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - copyright year
>>  - Merge branch 'master' into typejoin
>>  - sort order
>>  - Merge branch 'master' into typejoin
>>  - Merge branch 'master' into typejoin
>>  - Move dual to ASSERT only
>>  - Keep old version for verification
>>  - whitespace
>>  - Reimplement Type::join
>
> src/hotspot/share/opto/subnode.cpp line 2014:
> 
>> 2012:   const Type* in_type = phase->type(in1);
>> 2013:   if ((in_type->isa_int() && in_type->is_int()->_lo >= 0) ||
>> 2014:       (in_type->isa_long() && in_type->is_long()->_lo >= 0)) {
> 
> I'm a bit annoyed here because we look quite a lot inside the details of the implementation of the types. I'm not fan of the previous situation either, as at most one side of the `||` would make sense.
> 
> For instance, if we want to make use of bitwise information for this, we could look at the highest bit (that is a sign bit in two complement). That is just an example, we could find other tricks to conclude that an abstract int is non-negative that may not involve ranges (or not only ranges), and I find unfortunate to look inside the type, rather than the type telling. I think the usual approach would be to check that the guard/intersection (depending on the formalism) with the negative numbers is empty (or with non-negative numbers is the same), but we quickly have again the problem that `in_type` can be either int or long and a lot of ways to write that would need to split cases. Maybe an approximation, would be to have `TypeInt::is_non_negative` and alike not to overengineer guarding with arbitrary expression, but still limit the scope of who looks into the implementation?

But checking the bit is also looking into the details of the types, right? Trying to answer whether a value can be negative with `_lo >= 0` seems to be the most straightforward approach to me. Anyway, the internal details of `TypeInt` are designed to be exposed, and we use them all the time. The methods act more as utilities than encapsulations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28051#discussion_r2669566956