Optimize jump stubs on arm64

[EgorBo]

On x64 we emit the following code for jump stubs:

mov rax, 123456789abcdef0h
jmp rax

as I understand from

runtime/src/coreclr/vm/amd64/cgenamd64.cpp

Lines 505 to 507 in 70d20f1

	// mov rax, 123456789abcdef0h 48 b8 xx xx xx xx xx xx xx xx
	// jmp rax ff e0

while on arm64 we make a memory load (from data section via pc):

ldr x16, [pc, #8]
br  x16
[target address]

runtime/src/coreclr/vm/arm64/cgencpu.h

Lines 294 to 296 in eeb79b3

	// +0: ldr x16, [pc, #8]
	// +4: br x16
	// +8: [target address]

I'm just wondering if it's not faster to do what x64 does and emit the const directly even if it takes 4 instructions to populate it...

mov     x8, #9044
movk    x8, #9268, lsl #16
movk    x8, #61203, lsl #32
movk    x8, #43981, lsl #48
br      x8

I'm asking because I have a feeling that it could be a bottleneck if I read it correctly from the TE traces (Plaintext benchmark):

cc @dotnet/jit-contrib @jkotas

[EgorBo]

Also, doesn't arm64 allow us to do just br [pc, #8]? it doesn't.

[echesakov]

If distance between pCode and target smaller than 128MB I guess we could do

b <pcRelDistance>

[BruceForstall]

Wouldn't it take 4 instructions to populate an address constant in the worst case?

[kunalspathak]

We are not good in hoisting address constant population, so if this is part of the loop, we might regress.

[jkotas]

Note that we require that the target is atomically patchable without suspending the execution. It makes it close to impossible to split this into multiple instructions.

I agree that the whole scheme for how we deal with the precodes and back patching is likely very suboptimal on non-x86 architectures (and maybe even on current x86). I think the more optimal path may look like this:

• Loading of the indirection is inlined into the JITed code. The direct call to indirect jump that we have there today is replaced with indirect call - it should be an improvement. The JITed code will look like this:

...
    ldr    x16, [pc + 0x1230] // Indirection cell that lives in the local data section
    blx    x16
...

• Keep track of the indirection cells that live in the local data sections. If tiering comes up with a new copy of method, we need to patch them all to point to the new method.

• We can also consider emitting direct call to the actual method for cases when we know that the target method is not going to change because of it reached the final tier. The direct calls would have to be treated as if the method was inlined by profiler ReJIT.

[jkotas]

I'm just wondering if it's not faster to do what x64 does and emit the const directly even if it takes 3 instructions

My bet would be that the bottleneck is more caused more by the call + indirect jump combination than by the memory load. Patterns like that used to cause pipeline stalls on x86 in the past, and I think it is likely that they are problem for arm64 too.

[EgorBo]

@jkotas thanks for a detailed explanation! 👍

Wouldn't it take 4 instructions to populate an address constant in the worst case?

@BruceForstall Right, I was wondering if it's still faster, because otherwise I'd expect native compilers to always prefer doing a memory load from data section rather than doing 4 movs (e.g. https://godbolt.org/z/cWYsTq6P6). I played locally with llvm-mca tool targeting -mcpu=apple-a13:

From what I read it takes 3x less cycles to do 4 movs.

[jkotas]

I think we should look into optimizing the jump stubs and friends for arm64. I agree with your initial observation that there is likely bottleneck.

[EgorBo]

I guess we also more likely to hit a jump stub on ARM64, quoting jump-stubs.md:

The need for jump stubs only arises when jumps of greater than 2GB range (on x64; 128MB on arm64) are required

so even pretty simple TE benchmarks hit that.