RFR: 8315066: Add unsigned bounds and known bits to TypeInt/Long [v2]

Tobias Hartmann thartmann at openjdk.org
Tue Oct 31 08:44:31 UTC 2023


On Thu, 19 Oct 2023 18:38:05 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> I don't think splitting these 2 would ease reviewing
>> 
>> Okay, thanks for the details! Let's leave it as is then.
>> 
>>> Yes the sign of the result is determined by its sign bit so this patch does solve that issue.
>> 
>> I closed [JDK-8311597](https://bugs.openjdk.org/browse/JDK-8311597) as duplicate.
>> 
>>> I think the patch fully covers John's prototype
>> 
>> Okay, I leave it to @rose00 to decide if [JDK-8001436](https://bugs.openjdk.org/browse/JDK-8001436) should be closed as duplicate then.
>> 
>>> it simply moves the complexity and burden of correctness from xmeet where branching on the _dual field is pretty straightforward to xdual where this representation is a fair leap of faith
>> 
>> Thanks for summarizing. Right, I agree that in this case it's much cleaner to special case the dual types but I don't think that would apply in general to all the types (for example, `TypePtr::meet_instptr`). So this is all about consistency of new changes with existing code and I would prefer consistency over special casing. If we identify improvements to the existing representation of types, that should be done in a separate change and consistently over all types. I'm curious what other reviewers think though.
>
> @TobiHartmann I have tried your suggestion, it turns out that the interdependence between constraints makes it difficult to tolerate ambiguity in type presentations. Without knowing whether the context is a dual type or not, it is really hard to normalise the constraints, verify them and normalise the widen parameter. What do you think? Thanks.

Thanks for checking, @merykitty. Fair enough, I'm fine with leaving it as-is then. Let's see what other reviewers think.

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

PR Comment: https://git.openjdk.org/jdk/pull/15440#issuecomment-1786753029


More information about the hotspot-compiler-dev mailing list