8367341: C2: apply KnownBits and unsigned bounds to And / Or operations

[merykitty]

Hi,

This PR improves the implementation of AndNode/OrNode/XorNode::Value by taking advantages of the additional information in TypeInt. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a TypeInt separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.

Please take a look and leave your reviews, thanks a lot.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8367341: C2: apply KnownBits and unsigned bounds to And / Or operations (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27618/head:pull/27618
$ git checkout pull/27618

Update a local copy of the PR:
$ git checkout pull/27618
$ git pull https://git.openjdk.org/jdk.git pull/27618/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27618

View PR using the GUI difftool:
$ git pr show -t 27618

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27618.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back qamai! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@merykitty The following label will be automatically applied to this pull request:

• hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (46ce95fd)

[SirYwell]

Nice change overall.
I'm not sure how "easily" we can really see the benefit in the example of the interval splitting, but I leave that to others to judge.

I was just wondering, do you think it makes sense to move more such code into the RangeInference classes in future (e.g., for shift ops) or how we'll tell what to place where. From what it looks like the main reason currently is to use the TypeIntMirror classes for testability, which other node types definitely could benefit from as well.

[merykitty]

I'm not sure how "easily" we can really see the benefit in the example of the interval splitting, but I leave that to others to judge.

Without it, the simple inference function fails AndLNodeIdealizationTest because the current version also splits the analysis between the negative part and the non-negative part.

I was just wondering, do you think it makes sense to move more such code into the RangeInference classes in future (e.g., for shift ops) or how we'll tell what to place where. From what it looks like the main reason currently is to use the TypeIntMirror classes for testability, which other node types definitely could benefit from as well.

Yes that is entirely my intention, that for example, we only need to implement RangeInference::infer_left_shift and the unittest can be a simple:

class OpLeftShift;
class InferLeftShift:

TEST(opto, range_inference) {
  test_binary<OpLeftShift, InferLeftShift>();
}