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

[Emanuel Peter]

On Fri, 20 Jun 2025 08:16:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> A first part toward a better support of pure functions, but this time, with guidance from @iwanowww.
>> 
>> ## Pure Functions
>> 
>> Pure functions (considered here) are functions that have no side effects, no effect on the control flow (no exception or such), cannot deopt etc.. It's really a function that you can execute anywhere, with whichever arguments without effect other than wasting time. Integer division is not pure as dividing by zero is throwing. But many floating point functions will just return `NaN` or `+/-infinity` in problematic cases.
>> 
>> ## Scope
>> 
>> We are not going all powerful for now! It's mostly about identifying some pure functions and being able to remove them if the result is unused. Some other things are not part of this PR, on purpose. Especially, this PR doesn't propose a way to move pure calls around. The reason is that pure calls are later expanded into regular calls, which require a control input. To be able to do the expansion, we just keep the control in the pure call as well.
>> 
>> ## Implementation Overview
>> 
>> We created here some new node kind for pure calls, inheriting leaf calls, that are expanded into regular leaf calls during final graph reshaping. The possibility to support pure call directly in AD file is left open.
>> 
>> This PR also introduces `TupleNode` (largely based on an original idea/implem of @iwanowww), that just tie multiple input together and play well with `ProjNode`: the n-th projection of a `TupleNode` is the n-th input of the tuple. This is a convenient way to skip and remove nodes from the graph while delegating the difficulty of the surgery to the trusted IGVN's implementation.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mostly comments

@marc-chevalier Thanks for addressing my comments! I now have a few more for you :)

src/hotspot/share/opto/callnode.cpp line 1318:

> 1316:  * such a tuple, we let output Proj's idealization pick the corresponding input of the
> 1317:  * pure call, so jumping over it, and effectively, removing the call from the graph.
> 1318:  * This avoids doing the graph surgery manually, but leave that to IGVN

Suggestion:

 * This avoids doing the graph surgery manually, but leaves that to IGVN

src/hotspot/share/opto/callnode.cpp line 1341:

> 1339: }
> 1340: 
> 1341: Node* CallLeafPureNode::Ideal(PhaseGVN* phase, bool can_reshape) {

Did you make sure that this method is called from all its subclasses?

It seems to me that you just copied the code to the subclasses, rather than calling this method, am I right?

src/hotspot/share/opto/callnode.cpp line 1342:

> 1340: 
> 1341: Node* CallLeafPureNode::Ideal(PhaseGVN* phase, bool can_reshape) {
> 1342:   if (is_dead()) { // dead node

Suggestion:

  if (is_dead()) {

The comment seemed redundant. You could say who else is responsible of cleaning up the dead node though.

What would happen if the `CallLeafPureNode` loses  its control projection, but not the other uses? I don't even know if that is possible. What do you think?

src/hotspot/share/opto/callnode.hpp line 916:

> 914: };
> 915: 
> 916: class CallLeafPureNode : public CallLeafNode {

You need a short description about what this node is for. What are the assumptions about it?

src/hotspot/share/opto/divnode.cpp line 1522:

> 1520:   if (!can_reshape) {
> 1521:     return nullptr;
> 1522:   }

Would this prevent us from doing the `make_tuple_of_input_state_and_top_return_values` trick? Because it seems to me that we do not need to reshape the node for that, right? Maybe you  should reorder things for that?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25760#pullrequestreview-2946648813
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159274378
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159292773
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159277636
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159287237
PR Review Comment: https://git.openjdk.org/jdk/pull/25760#discussion_r2159289092