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

On 18.08.2026 13:12, Jan Beulich wrote:
> 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.

Yet then it looks to be emitting suitable changed relocation types, i.e. the
result is still self-consistent.

Jan