[llvm-branch-commits] [NFC][ELF][AArch64] Don't duplicate addRelativeReloc call for MTE globals (PR #171181)

[via llvm-branch-commits]

llvmbot wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-lld-elf

Author: Jessica Clarke (jrtc27)

<details>
<summary>Changes</summary>

This call to addRelativeReloc is the same as the one at the end of the
function, so skip the relrDyn code for this case and add the special
out-of-bounds handling code to the end of the function. This makes it
obvious where MTE globals differ in behaviour rather than having to
compare the two different implementations.


---
Full diff: https://github.com/llvm/llvm-project/pull/171181.diff


1 Files Affected:

- (modified) lld/ELF/Relocations.cpp (+13-16) 


``````````diff
diff --git a/lld/ELF/Relocations.cpp b/lld/ELF/Relocations.cpp
index e3bb2e8b6e805..977dba0555dac 100644
--- a/lld/ELF/Relocations.cpp
+++ b/lld/ELF/Relocations.cpp
@@ -707,22 +707,6 @@ static void addRelativeReloc(Ctx &ctx, InputSectionBase &isec,
   bool isAArch64Auth =
       ctx.arg.emachine == EM_AARCH64 && type == R_AARCH64_AUTH_ABS64;
 
-  if (sym.isTagged() && !isAArch64Auth) {
-    part.relaDyn->addRelativeReloc<shard>(ctx.target->relativeRel, isec,
-                                          offsetInSec, sym, addend, type, expr);
-    // With MTE globals, we always want to derive the address tag by `ldg`-ing
-    // the symbol. When we have a RELATIVE relocation though, we no longer have
-    // a reference to the symbol. Because of this, when we have an addend that
-    // puts the result of the RELATIVE relocation out-of-bounds of the symbol
-    // (e.g. the addend is outside of [0, sym.getSize()]), the AArch64 MemtagABI
-    // says we should store the offset to the start of the symbol in the target
-    // field. This is described in further detail in:
-    // https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst#841extended-semantics-of-r_aarch64_relative
-    if (addend < 0 || static_cast<uint64_t>(addend) >= sym.getSize())
-      isec.addReloc({expr, type, offsetInSec, addend, &sym});
-    return;
-  }
-
   // Add a relative relocation. If relrDyn section is enabled, and the
   // relocation offset is guaranteed to be even, add the relocation to
   // the relrDyn section, otherwise add it to the relaDyn section.
@@ -735,6 +719,8 @@ static void addRelativeReloc(Ctx &ctx, InputSectionBase &isec,
   RelrBaseSection *relrDyn = part.relrDyn.get();
   if (isAArch64Auth)
     relrDyn = part.relrAuthDyn.get();
+  else if (sym.isTagged())
+    relrDyn = nullptr;
   if (relrDyn && isec.addralign >= 2 && offsetInSec % 2 == 0) {
     relrDyn->addRelativeReloc<shard>(isec, offsetInSec, sym, addend, type,
                                      expr);
@@ -745,6 +731,17 @@ static void addRelativeReloc(Ctx &ctx, InputSectionBase &isec,
     relativeType = R_AARCH64_AUTH_RELATIVE;
   part.relaDyn->addRelativeReloc<shard>(relativeType, isec, offsetInSec, sym,
                                         addend, type, expr);
+  // With MTE globals, we always want to derive the address tag by `ldg`-ing
+  // the symbol. When we have a RELATIVE relocation though, we no longer have
+  // a reference to the symbol. Because of this, when we have an addend that
+  // puts the result of the RELATIVE relocation out-of-bounds of the symbol
+  // (e.g. the addend is outside of [0, sym.getSize()]), the AArch64 MemtagABI
+  // says we should store the offset to the start of the symbol in the target
+  // field. This is described in further detail in:
+  // https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst#841extended-semantics-of-r_aarch64_relative
+  if (sym.isTagged() && !isAArch64Auth &&
+      (addend < 0 || static_cast<uint64_t>(addend) >= sym.getSize()))
+    isec.addReloc({expr, type, offsetInSec, addend, &sym});
 }
 
 template <class PltSection, class GotPltSection>

``````````

</details>


https://github.com/llvm/llvm-project/pull/171181