RFR: 8366815: C2: Delay Mod/Div by constant transformation

Hannes Greule hgreule at openjdk.org
Mon Oct 27 18:07:04 UTC 2025


On Fri, 24 Oct 2025 18:04:57 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> If we want to to keep expanded shape while being able to compute its type as if it were the original node, then a new flavor of Cast node may help. The one which keeps the node type and its inputs and can run Value() as if it were the original node.

This is what we'd like to achieve, yes. This PR is basically just a simple workaround. So I guess it comes down to:
Do we want to have a simple workaround for common cases? And if so,
1. Do we want to use this delay mechanism, or
2. Do we want to use Cast nodes

I assume that the proper solution in form of a Cast-like node requires some more effort, and I'm not sure if anyone has the resources to work on that in the near future.


> What I don't know: how does that interact with other IGVN optimizations, especially those that want to pattern match specific nodes? Inserting such special cast nodes could interrupt `Ideal` optimizations, current pattern matching would not know how to deal with it. Probably it is not a big issue, but I'm not sure.

This isn't much different from methods like `uncast` I think. New methods like `get_in_of_type(index, opcode)` could help in such cases (check for the different ins of the cast), and maybe be even useful for other code in general.

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

PR Comment: https://git.openjdk.org/jdk/pull/27886#issuecomment-3452639986


More information about the hotspot-compiler-dev mailing list