RFR: 8347917: AArch64: Enable upper GPR registers in C1

[Andrew Haley]

On Thu, 16 Jan 2025 12:26:43 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> This small change enables upper GPR registers in C1 so they are used, and used similar to C2. r19-r26 are declared as caller-saved and enabled, r27 (rheapbase) and r29 (fp) are declared caller-saved and enabled conditionally similar to C2.
> 
> r18 is excluded on masOS and Windows as before. r27 is excluded when `UseCompressedOops` is on and `CompressedOops::base() != nullptr,` r29 is excluded when `PreserveFramePointer` is on.
> 
> Registers are declared caller-saved in c1_FrameMap_aarch64.cpp, conditionally enabled ones are in the tail of enabled range which is adjusted in c1_FrameMap_aarch64.hpp, the code there was made similar to x86 (JDK-6985015).
> 
> Register ranges are also updated in the linear scan itself and in OOP map generation.
> 
> Having more allocatable registers help to avoid spills in register hungry code and thus improve performance and code density and simplify compilation. In practice the code that operates so many values is not too frequent and upper registers are used less frequently than first ones. To perform testing it turned to be useful to run C1 in a special mode when registers are allocated from upper to lower in LinearScanWalker::find_free_reg():
> 
> 
> -  for (int i = _first_reg; i <= _last_reg; i++) {
> +  for (int i = _last_reg; i >= _first_reg; i--) {
> 
> 
> It was also useful to run the JVM with C1 compilation only and with different GCs and small heaps like `-XX:TieredStopAtLevel=1 -Xmx256m -XX:+UseSerialGC`.
> 
> Tier1-3 jtreg tests showed no regression on linux-aarch64 (release, slowdebug, Xcomp) with either direct or reversed register allocation order. Windows and macOS were also tested to check r18 handling, +-CompressedOops and +-PreserveFramePointer combinations were tested.
> 
> SHA3 Java implementation is as an example of register hungry code. Throughput results greatly depend on the actual CPU being used. On Graviton 2 the improvement in the dedicated micro-benchmark is ~**19%** for longer arrays (`-XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -jar benchmarks.jar -p digesterName=SHA3-256 -p length=16384 MessageDigests.digest$`).

Yes, good catch. This is interesting and perhaps worthwhile, but C1 performace most of the time isn't so much to dominated by compiled code but by profile counters, at least if _The Cost of Profiling in the HotSpot Virtual Machine_ is to be believed. None the less, I think this patch makes sense, even if most people (users of tiered compilation) won't see a huge benefit.

I think this should be worth pushing whan we're in Phase 1 of JDK 25.

For the sake of C1, it might be useful to allocate high registers (`r20` and up) preferentially in order to minimize the footprint of VM calls, which use the native convention. That would definitely be of interest

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

PR Comment: https://git.openjdk.org/jdk/pull/23152#issuecomment-2596003972