RFR: 8020282: Generated code quality: redundant LEAs in the chained dereferences [v2]

[Manuel Hässig]

On Thu, 12 Jun 2025 12:59:51 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> Manuel Hässig has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Add comment to benchmark as to why we fix the heap size
>>  - Add missing null chec
>>  - Fix typos
>
> test/hotspot/jtreg/compiler/codegen/TestRedundantLea.java line 1:
> 
>> 1: /*
> 
> The new test cases are very thorough and well-documented, but the IR conditions checked are very specific, which might become a maintainability burden as library code, intrinsics, and platform definitions change. Is there anything that could be relaxed while still checking that the optimization is somehow applied (or not applied)?
> Two things that come to mind are 1) extracting standalone Java programs that trigger the same scenarios as the current library calls and 2) relaxing the IRNode definitions and the corresponding IR check preconditions (e.g. defining and matching a single `leaP.*` node instead of specialized versions for different heap configurations, or defining and matching a single `decodeHeapOop.*` node).

The best way to get this to be maintainable would be the ability to say "between phase A and B I expect to see two fewer DecodeN's", which is currently not possible in the IR-Framework. I think that the number of `DecodeHeapOopOffset_not_null`s is currently the main maintenance burden.

Matching `leaP*` Nodes is the next best option. The main reason I went for such specific IR conditions is to show that the peephole works for all `leaP*` variants. If that is not valuable enough, then this would get rid of all the heap size related cruft.

The most finicky tests are `RegexFind` and `StringInflate`. These could be outright removed, because they mainly show interesting behavior if all VM intrinsics are disabled. I was also not able to extract these tests into standalone tests, despite some effort.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25471#discussion_r2142970431