Re: [PATCH] AArch64: Optimize ADD relocations that resolve to zero

On 18.08.2026 12:51, Sivan Shani wrote:
> From: Sivan Shani <[email protected]>
> 
> I would like to ground and clarify the discussion with a concrete example:
> 
> test.s
> ```
> .text
> .global _start
> _start:
>     add x0, x1, #:tprel_hi12:tlsvar
>     add x2, x2, #:lo12:absvar
>     ret
> 
> .section .tdata,"awT",@progbits
> .align 3
> tlsvar:
>     .hword 0xf0f0
> 
> .data
> .balign 4096
> absvar:
>     .hword 0xf0f0
> ```
> 
> 1. Default: final link
> 
> The relocations are consumed, idempotency is irrelevant:
> 
> ```
> $AS -o test.o test.s
> $LD -o test.elf test.o
> $OBJDUMP -dr test.elf
> 
> 400120:	aa0103e0 	mov	x0, x1
> 400124:	d503201f 	nop
> ```
> 
> 2. Relocatable link
> 
> With '--relocatable', no relocations or optimizations are applied:
> 
> ```
> $LD --relocatable -o test.elf test.o
> $OBJDUMP -dr test.elf
> 
> 0:	91400020 	add	x0, x1, #0x0, lsl #12
> 			0: R_AARCH64_TLSLE_ADD_TPREL_HI12	tlsvar
> 4:	91000042 	add	x2, x2, #0x0
> 			4: R_AARCH64_ADD_ABS_LO12_NC	.data
> ```
> 
> idempotency is preserved/irrelevant
> 
> 3. Final link with '--emit-relocs'
> 
> ```
> $LD --emit-relocs -o test.elf test.o
> $OBJDUMP -dr test.elf
> 
> 400120:	aa0103e0 	mov	x0, x1
> 			400120: R_AARCH64_TLSLE_ADD_TPREL_HI12	tlsvar
> 400124:	d503201f 	nop
> 			400124: R_AARCH64_ADD_ABS_LO12_NC	.data
> ```
> 
> This is the case that needs a policy decision. The relocation records are retained,
> but their target instructions are not.
> 
> '--emit-relocs' retain relocation information mainly for post link analysis
> and optimization tools. Two possible interpretations:
> 
> 1. Retained relocations must remain applicable to their target instructions.
> 2. Retained relocations principally describe the provenance of the linked code 
>    and are not necessarily safe to apply again after linker relaxation.
> 
> The first interpretation requires disabling such optimization under '--emit-relocs',
> or rewriting/removing the retained relocation.
> 
> The second interpretation permits the current behavior, but post link consumers
> must tolerate relocations whose original instruction class has changed.

Relocations having "instruction class" isn't a universal thing anyway. If you
wanted to build on that, it would be pretty much arch-specific.

> The retained
> information may still identify the affected address, symbol and original relocation
> expression, perhaps even sufficient to reconstruct some of the original instructions.
> 
> There is existing precedent that linker processing is not universally idempotent.
> GOT and PLT generating relocations have allocation side effects, and some TLS
> relaxations rewrite instruction sequences while relocations are retained.
> It would be useful to establish whether this behavior is regarded as intentional
> precedent or something to change.
> 
> LLD also performs relaxations with '--emit-relocs', although '--no-relax' can be
> used when preserving unrelaxed instruction/relocation pairs is required. We could
> consider giving this optimization the same policy control.
> 
> Therefore, the question is specifically what guarantee '--emit-relocs' should provide:
> 
> - relocations that remain applicable, or
> - relocation metadata that may describe code before linker optimization.
> 
> If the latter is acceptable, retaining the current behavior may be reasonable.
> If the former is required, the optimization should be suppressed or the retained
> relocations adjusted.

Have you looked at what other ports do? The x86-64 one, I think, wouldn't
skip any of the optimizations it does. That said, while I think that for
analysis tools option 2 above would likely be fine, I'm less certain about
tools wanting to do further optimization. Maybe you need to give people
control over the level of optimization done?

Jan