8366815: C2: Delay Mod/Div by constant transformation

[SirYwell]

The test cases show examples of code where Value() previously wasn't run because idealization took place before, resulting in less precise type analysis.

Please let me know what you think.

---

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-8366815: C2: Delay Mod/Div by constant transformation (Enhancement - P4)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27886

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back hgreule! 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]

@SirYwell 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 (6a392224)

[mhaessig]

Thank you for working on this, @SirYwell. This seems like a tricky problem. To be honest, the fix seems a bit hacky. Have you explored any alternatives to this method of delaying the optimizations?

I kicked off some testing in the meantime that I will report back upon completion.

[mhaessig]

Suggested change

	// Keep this node as-is for now; we want Value() and
	// other optimizations checking for this node type to work
	// Keep this node as-is initially; we want Value() and
	// other optimizations checking for this node type to work.

This is a small nit: I find it confusing to talk about "for now" in a method that is called at almost every stage of the compilation. Perhaps "initially" conveys the intention of first letting other optimizations do their magic first a bit better.

[SirYwell]

Thank you for working on this, @SirYwell. This seems like a tricky problem. To be honest, the fix seems a bit hacky. Have you explored any alternatives to this method of delaying the optimizations?

I kicked off some testing in the meantime that I will report back upon completion.

Thanks for running tests. I tried delaying until post loop opts, but that prevents some vectorization and isn't really less hacky I guess. I didn't find any other good existing approach. Calculating Value before Ideal would work, but I assume that it is rarely useful, with Div/Mod being an exception. I a dream world, I guess we would have e-graphs or something similar, which would allow calculating a more precise type from different alternatives.

If you can think of a better approach, please let me know.