RFR: 8347917: AArch64: Enable upper GPR registers in C1 [v3]
Dmitry Chuyko
dchuyko at openjdk.org
Wed Jan 29 12:01:23 UTC 2025
> 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$`).
Dmitry Chuyko has updated the pull request incrementally with one additional commit since the last revision:
Exclude r29 from oop map
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/23152/files
- new: https://git.openjdk.org/jdk/pull/23152/files/5e8b13d8..1c3dcaa7
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=23152&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=23152&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/23152.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/23152/head:pull/23152
PR: https://git.openjdk.org/jdk/pull/23152
More information about the hotspot-compiler-dev
mailing list