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