RFR: 8361582: AArch64: Some ConH values cannot be replicated with SVE [v4]
Bhavana Kilambi
bkilambi at openjdk.org
Tue Aug 12 10:28:18 UTC 2025
On Mon, 11 Aug 2025 12:09:18 GMT, Andrew Haley <aph at openjdk.org> wrote:
> For `loadConH`, LLVM and GCC use
>
> ```
> mov wscratch, #const
> dup v0.4h, wscratch
> ```
>
> We should investigate that.
>
> As far as I can see, LLVM and GCC do this for all vector immediates that don't need more than 2 movz/movk instructions.
Just a quick look at what can be done to improve the codegen -
The code shown above is Neon and this is similar to what we generate in hotspot as well (for Neon) -
```
0x0000e8a5e482ea80: mov w8, #0x40b // #1035
0x0000e8a5e482ea84: dup v18.8h, w8
Only on SVE machines with >16B vectors, we load from the constant table -
```
0x0000e9cdc902e370: ldr s16, 0x0000e9cdc902e280 ; {section_word}
0x0000e9cdc902e440: mov z17.h, p7/m, h16
We could generate a similar `mov` and a `dup` from a GPR (instead of immediate) even in the SVE case (a good part of my patch + JTREG test *could* be redundant). I'll update the patch as soon as I can. Thanks a lot for your suggestion
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26589#issuecomment-3178735447
More information about the hotspot-compiler-dev
mailing list