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

Jan Beulich jbeulich@suse.com
Fri Aug 14 12:40:25 GMT 2026


On 14.08.2026 13:46, Alice Carlotti wrote:
> On Fri, Aug 14, 2026 at 10:12:39AM +0200, Jan Beulich wrote:
>> On 13.08.2026 19:12, Alice Carlotti wrote:
>>> On Fri, Jul 24, 2026 at 09:58:59AM +0000, Sivan Shani wrote:
>>>> The "ELF for the Arm 64-bit Architecture" specification, section 5.7.9,
>>>> recommends that linkers optimize ADD instructions whose immediate
>>>> becomes zero after relocation.  In particular:
>>>>
>>>>    ADD x0, x1, 0
>>>>    ADD x2, x2, 0
>>>>
>>>> may be replaced with:
>>>>
>>>>    MOV x0, x1
>>>>    NOP
>>>>
>>>> Apply this optimization to all supported relocations that set an ADD
>>>> immediate field.
>>>
>>>
>>> I think this optimization is invalid if we're still emitting relocations,
>>> because it breaks idempotency, so we probably need to add a check for that.
>>>
>>> I'm not particularly familiar with this generic part of the linker, so I'd
>>> appreciate any clarification from other maintainers on how to check this.
>>
>> Do you perhaps refer to the bfd_link_relocatable() predicate?
> 
> I guessed that was at least part of it.  Some places (e.g.
> bfd/elfnn-aarch64.c-8727) also check info->emitrelocations - do we need to
> check both of these values, or should bfd_link_relocatable() suffice?

That depends on various properties, first of all: Are these relocation types
permitted at all in non-ET_REL binaries? If they are, semantics of these
relocs may differ there, which may affect whether the optimization then would
need skipping.

Jan


More information about the Binutils mailing list