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

[Sivan Shani]

From: Sivan Shani <sivan.sgani@arm.com>

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. 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.