Add constant table to AArch64 to replace mov sequences

[a74nh]

Looking at the AArch64 assembly, it's full of mov sequences to load constants, for example:

  0x0000ffff7c9c21d4: mov	x0, #0x89c0 
  0x0000ffff7c9c21d8: movk	x0, #0x1b80, lsl #16
  0x0000ffff7c9c21dc: movk	x0, #0xffff, lsl #32

Ideally these constants should be placed in a constants table and loaded with a single ldr instruction (plus the initial adrp instruction to load the table base).
Code patching should be updated to patch the table contents.

SPARC already has this - see LoadConstantFromTable in SPARCMoveFactory.
AArch64 has a commented out reference a LoadConstantFromTable, but no other code, so looks like there may have once been a plan to add this (... or it was just copied from SPARC).

Anything using const2reg should be patched this way. As a first pass maybe just do constants not marked as needsImmAnnotation and non zero (as zero constants are usually patched up later too - might be useful to make this more obvious in the code). However, that's a very reduced subset, so may show no obvious gains.

Small constants can still use a mov.

Need to be careful to make sure the loads don't result in tlb and cache misses.

[adinn]

Looking at the AArch64 assembly, it's full of mov sequences to load constants, for example:

0x0000ffff7c9c21d4: mov x0, #0x89c0
0x0000ffff7c9c21d8: movk x0, #0x1b80, lsl #16
0x0000ffff7c9c21dc: movk x0, #0xffff, lsl #32

Ideally these constants should be placed in a constants table and loaded with a single ldr instruction (plus the initial adrp instruction to load the table base).
Code patching should be updated to patch the table contents.

Are you talking about doing this for native images or for code that is installed into OpenJDK? In the latter case I think you need to discuss this with @theRealAph.

SPARC already has this - see LoadConstantFromTable in SPARCMoveFactory.
AArch64 has a commented out reference a LoadConstantFromTable, but no other code, so looks like there may have once been a plan to add this (... or it was just copied from SPARC).

I believe the plan was actually not to do what you are suggesting. That mirrors the choice made for the OpenJDK compilers.

[a74nh]

Are you talking about doing this for native images or for code that is installed into OpenJDK? In the latter case I think you need to discuss this with @theRealAph.

I'm thinking about both here.

I believe the plan was actually not to do what you are suggesting. That mirrors the choice made for the OpenJDK compilers.

Hmm, interesting. Do you know why OpenJDK decided on that?

Note, that in A72's (and maybe prior, I'm not sure), the mov sequences will be fused [1], but that's no longer necessarily the case in new cores. It's possible this is more important for things like Graviton2.

[1] https://static.docs.arm.com/uan0016/a/cortex_a72_software_optimization_guide_external.pdf section 4.11

[fernando-valdez]

@christianwimmer, is this request still valid considering the current state of the native image?

[christianwimmer]

@teshull ?

[fernando-valdez]

Closing this ticket due to the lack of response. Feel free to reopen this ticket If the problem persists.