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

[Kangcheng Xu]

On Mon, 2 Jun 2025 11:50:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> 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?

Hello @eme64.  e1fd025b26e3d54e6455f63577a4649986864ffc updated the allow swapping LHS and RHS. It also added more test patterns with IR verification on cases that should (and should not) pass. I've left comments indicating some patterns could be potentially optimized in the future. 

I don't see conflict with main branch. Thanks for reviewing!

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

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