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