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