RFR: 8347901: C2 should remove unused leaf / pure runtime calls

Marc Chevalier mchevalier at openjdk.org
Fri May 9 16:08:55 UTC 2025


On Tue, 6 May 2025 18:18:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>  making them expensive nodes (to avoid commoning during GVN)

Good point!

I still think I don't get everything. Let me try to sum up what I think I should do.

For now, I don't want to mess with control, but I should prepare the field. Using general Call nodes for pure calls was pretty difficult: Call nodes have too much opinion, assumptions to easily work with for pure calls. But eventually, I want to change the nodes I'm using into a Call node, and more precisely a CallLeaf (I suspect once I'm done doing all I can do with pure calls, so in macro expansion, it's fine). To be able to do this transformation, I need to know control at this point. My goal is to start with control-less nodes, but find the late control during loop optimization, control-pin them at this point (because that's when the information is available) with both control input and output (needed for the expansion in CallLeaf), and continuing with control-pinned nodes. For now, I'm happy with the control I get from parsing.

So, under my nodes, I need 2 outputs: control and data (everywhere now, and at least after control-pinning in the follow-up). I should then make ModFloating/ModD/ModF sub-classes of `MultNode` (I guess, I can make ModFloating a direct sub-class of `MultNode`. And I can introduce new node types for native math calls that would behave similarly wrt to elimination (and pinning in the future), and would also expand into `CallLeaf`. A weirdness of these nodes is that they would be CFG or not whether they are pinned already, and not depending on their type, but I'm not aware of a fundamental issue about that, as long as the change doesn't happen in the middle of a phase where it's relevant.

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

PR Comment: https://git.openjdk.org/jdk/pull/24966#issuecomment-2867105355


More information about the graal-dev mailing list