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

Jan Beulich <[email protected]>
Newsgroups gmane.comp.gnu.binutils
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.