RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or operations [v2]

[Emanuel Peter]

On Wed, 15 Oct 2025 08:18:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/rangeinference.hpp line 218:
>> 
>>> 216:   bool contains(U u) const;
>>> 217:   bool contains(const TypeIntMirror& o) const;
>>> 218:   bool operator==(const TypeIntMirror& o) const;
>> 
>> Could we limit this to `DEBUG_ONLY`?
>
> Maybe, it disables these gtest in product builds, however. What do you think?

Right, I see. I suppose we can keep it. Can you somehow make it clear which block it is, maybe with some start/end markers?

I was wondering if the method below is still part of it, but I don't think so. But it was unclear at first.

>> src/hotspot/share/opto/rangeinference.hpp line 230:
>> 
>>> 228: // TypeLong*, or they can be TypeIntMirror which behave similar to TypeInt* and TypeLong* during
>>> 229: // testing. This allows us to verify the correctness of the implementation without coupling with
>>> 230: // the hotspot compiler allocation infrastructure.
>> 
>> This sounds a bit like a hack, but maybe a currently necessary one. But it sounds like we are passing something different in the production code vs in gtest testing code, and that's not ideal.
>> 
>> I suppose an alternative would be to always do the transition from `TypeInt` -> `TypeIntMirror`, before passing it into `RangeInference`. Would that be too much overhead, or have other downsides? I suppose an issue with that is how do you get back a `TypeInt` at the end... yeah not ideal. So maybe your hack is required.
>> 
>> It would have been nice if we could just compose `TypeIntMirror` inside `TypeInt`, but maybe even that does not solve the whole problem.
>> 
>> What do you think?
>
> In the strict sense, what is passed in product code and what is passed in gtest will never be the same. This is because `TypeInt` is the set of 32-bit integral values, while we do testing on 3-bit integral values. However, with templates, we can be much more confident since we know that the code being executed for `intn_t<3>` and `jint` is the same one, just specialized with different template parameters. With this approach, I believe we achieve the best similarity between what is executed and what is tested.

Hmm I see. Right because we cannot actually ever pass a `TypeInt` because of the allocators. That's a shame. But I think it is still worth doing the testing you are doing. So let's just go with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27618#discussion_r2432293070
PR Review Comment: https://git.openjdk.org/jdk/pull/27618#discussion_r2432297007