RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

[Andrew Haley]

On Mon, 23 Dec 2024 10:45:00 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.
> 
> This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).
> 
> After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.
> 
> Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

In general I like this very much.
If I were you I'd count how often `legitimize_address` has to split an instruction, and also count the total size of all C2 compilations over a run. I'd perhaps run jshell or javac all of java.base. Then we'd know how rare `legitimize_address` splitting is.
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/22862#issuecomment-2560171145