You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In llvm/llvm-project#138254 a case has emerged where there are two ADRP/LDR accesses to a symbol within a function. One of these sequences can be optimised, the other cannot. The function also has a branch destination between the optimisable ADRP/LDR. This can result in the unoptimised ADRP being combined with the optimised LDR (ADD in this case) leading to incorrect results.
The assembly (derived from C code compiled with GCC 9.3)
foo:
.LFB1:
.cfi_startproc
cmp x0, 0
bge .L8
adrp x2, :got:b // Optimised to adrp x2, b
.L9:
ldr x2, [x2, :got_lo12:b] // Optimised to adr x2, [x2 :lo12: b]
add x0, x2, x1
b bar
.p2align 2,,3
.L8:
stp x29, x30, [sp, -32]!
.cfi_def_cfa_offset 32
.cfi_offset 29, -32
.cfi_offset 30, -24
adrp x2, :got:b // Can't be optimised due to add that is in way.
add x0, x0, 1 // although in theory could be out of range of b.
ldr x3, [x2, :got_lo12:b]
add x0, x3, x0
mov x29, sp
stp x2, x1, [sp, 16]
bl bar
ldp x2, x1, [sp, 16]
ldp x29, x30, [sp], 32
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
b .L9
At the moment, according to our existing condition list [1] the linker is permitted to make this transformation. We need to find some words to ensure that the linker only apply the optimisation for b if all of the ADRP/LDR GOT relative accesses to b can be optimised.
The ADRP, ADD (non-got relative) transformation to NOP, ADR is saft to do partially as even if the first part of the ADRP is performed and then there's a jump to the middle of an optimised sequence, the ADR will overwrite it with the correct value.
In llvm/llvm-project#138254 a case has emerged where there are two ADRP/LDR accesses to a symbol within a function. One of these sequences can be optimised, the other cannot. The function also has a branch destination between the optimisable ADRP/LDR. This can result in the unoptimised ADRP being combined with the optimised LDR (ADD in this case) leading to incorrect results.
The assembly (derived from C code compiled with GCC 9.3)
At the moment, according to our existing condition list [1] the linker is permitted to make this transformation. We need to find some words to ensure that the linker only apply the optimisation for
b
if all of the ADRP/LDR GOT relative accesses tob
can be optimised.The ADRP, ADD (non-got relative) transformation to NOP, ADR is saft to do partially as even if the first part of the ADRP is performed and then there's a jump to the middle of an optimised sequence, the ADR will overwrite it with the correct value.
[1] https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#579relocation-optimization
The text was updated successfully, but these errors were encountered: