RFR: 8347555: [REDO] C2: implement optimization for series of Add of unique value [v7]

[Emanuel Peter]

On Wed, 28 May 2025 14:47:02 GMT, Kangcheng Xu <kxu at openjdk.org> wrote:

>> @tabjy Thanks for your patience, this one took me longer than I wanted. I responded like this above:
>> 
>>> Hmm, ok I see. Why don't you remove the asserts for now, and we see how clear the code looks now. I think I asked for the consistency check because I was confused by the previous code structure. Maybe it is ok now as it is.
>
> Ping @eme64 again for awareness. :)

@tabjy

> I could, at very least, try to swap LHS and RHS if no match is found

I think that would be a good idea, and not very hard. You can just have a function `add_pattern(lhs, rhs)`, and then run it also with `add_pattern(rhs, lhs)` for **swapping**.

Personally, I would have preferred a recursive algorithm, but that could have some compile time overhead. @chhagedorn Was a little more skeptical about the recursive algorithm.

It seems the motivation for this change is the benchmark from here:
ArithmeticCanonicalizationBenchmark
https://ionutbalosin.com/2024/02/jvm-performance-comparison-for-jdk-21/#jit-compiler

This benchmark is of course somewhat arbitrary, and so are now all of your added patterns. Having a most general solution would be nice, but maybe the recursive algorithm is too much, I'm not 100% sure. Of course we now still have cases that do not optimize/canonicalize, and so someone could write a benchmark for those cases still.. oh well.

What I would like to see for **testing**: add some more patterns with IR rules. More that now optimize, and also a few that do not optimize, just so we have a bit of a sense what we are still missing.

@rwestrel Filed this issue. I wonder: what do you think we should do here? How general should the optimization/canonicalization be?

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

PR Comment: https://git.openjdk.org/jdk/pull/23506#issuecomment-2930295143