RFR: 8328865: [c2] No need to convert "(x+1)+y" into "(x+y)+1" when y is a CallNode [v2]

[Dean Long]

On Wed, 27 Mar 2024 08:45:55 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> This patch prohibits the conversion from  "(x+1)+y" into "(x+y)+1" when y is a CallNode to reduce unnecessary spillcode and ADDNode.
>> 
>> Testing: tier1-3 in x86_64 and LoongArch64
>> 
>> JMH in x86_64:
>> <pre>
>> before:
>> Benchmark           Mode  Cnt      Score   Error  Units
>> CallNode.test      thrpt    2  26397.733          ops/s
>> 
>> after:
>> Benchmark           Mode  Cnt      Score   Error  Units
>> CallNode.test      thrpt    2  27839.337          ops/s
>> </pre>
>
> SUN Guoyun has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8328865: [c2] No need to convert "(x+1)+y" into "(x+y)+1" when y is a CallNode
>  - 8328865: [c2] No need to convert "(x+1)+y" into "(x+y)+1" when y is a CallNode

In general, we can't move a call left or right past something with side-effects or memory effects, right?  This seems like the wrong place to be moving a Call, except relative to easy values like constants.

For loop invariants, it seems like they could be grouped together on either side, but don't loop optimizations take care of that already?

And it seems like a comprehensive cost analysis would need to take into account the cost of a spill vs an add.  If we can rematerialize a value using (reg + reg) instead of a load from memory, that seems like a win, but for more complicated expressions that can be done outside the loop, rematerializing from memory could be best.

So does this change really belong in AddNode::Ideal()?

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

PR Comment: https://git.openjdk.org/jdk/pull/18482#issuecomment-2031398326