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

[Hannes Greule]

On Mon, 27 Oct 2025 18:39:07 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.
>
>> This PR is basically just a simple workaround.
> 
> I'm not against proposed solution, just want to be sure we know its limitations and have a proper tool to avoid such bugs in the future.

@iwanowww I hope I properly addressed your suggestions, could to take another look? Thanks!

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

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