Skip to content

lld: Target-specific section-folding logic for ICF #133990

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pranavk
Copy link
Contributor

@pranavk pranavk commented Apr 1, 2025

This is needed for AArch64 when we try to fold two sections with unpaired ADRP/LDR relocations in them.

This is needed when for AArch64 we try to fold two sections with
unpaired ADRP/LDR relocations.
Copy link

github-actions bot commented Apr 1, 2025

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:
git-clang-format --diff HEAD~1 HEAD --extensions h,cpp -- lld/ELF/Arch/AArch64.cpp lld/ELF/ICF.cpp lld/ELF/Target.h
View the diff from clang-format here.
diff --git a/lld/ELF/Arch/AArch64.cpp b/lld/ELF/Arch/AArch64.cpp
index b42711a81..23a670c9d 100644
--- a/lld/ELF/Arch/AArch64.cpp
+++ b/lld/ELF/Arch/AArch64.cpp
@@ -982,11 +982,12 @@ void AArch64::relocateAlloc(InputSectionBase &sec, uint8_t *buf) const {
 bool AArch64::canFoldSection(const SmallVector<Relocation> &relocs) const {
   // Section cannot be folded as part of ICF if it contains unpaired relocations
   // eg: ADR_GOT_PAGE and LD64_GOT_LO12_NC don't point to same symbol.
-  SmallSet<Symbol*, 4> syms;
+  SmallSet<Symbol *, 4> syms;
   for (const Relocation &reloc : relocs) {
     if (reloc.type == R_AARCH64_ADR_GOT_PAGE)
       syms.insert(reloc.sym);
-    else if (reloc.type == R_AARCH64_LD64_GOT_LO12_NC && !syms.contains(reloc.sym))
+    else if (reloc.type == R_AARCH64_LD64_GOT_LO12_NC &&
+             !syms.contains(reloc.sym))
       return false;
   }
 
diff --git a/lld/ELF/ICF.cpp b/lld/ELF/ICF.cpp
index 4493ba4a0..846aed50d 100644
--- a/lld/ELF/ICF.cpp
+++ b/lld/ELF/ICF.cpp
@@ -322,7 +322,8 @@ bool ICF<ELFT>::constantEq(const InputSection *secA, Relocs<RelTy> ra,
   }
 
   // Target-specific section-folding logic based on section's relocation list
-  if (!ctx.target->canFoldSection(relocsA) || !ctx.target->canFoldSection(relocsB))
+  if (!ctx.target->canFoldSection(relocsA) ||
+      !ctx.target->canFoldSection(relocsB))
     return false;
 
   return true;
diff --git a/lld/ELF/Target.h b/lld/ELF/Target.h
index 169bd17ec..76c3d4a39 100644
--- a/lld/ELF/Target.h
+++ b/lld/ELF/Target.h
@@ -102,8 +102,11 @@ public:
   virtual void applyJumpInstrMod(uint8_t *loc, JumpModType type,
                                  JumpModType val) const {}
 
-  // Used by ICF to determine if section full of @relocs can be folded safely with another
-  virtual bool canFoldSection(const SmallVector<Relocation> &relocs) const { return true; }
+  // Used by ICF to determine if section full of @relocs can be folded safely
+  // with another
+  virtual bool canFoldSection(const SmallVector<Relocation> &relocs) const {
+    return true;
+  }
 
   virtual ~TargetInfo();
 

rai->getType(ctx.arg.isMips64EL), 0, addA, &sa});
relocsB.push_back(
{ctx.target->getRelExpr(rbi->getType(ctx.arg.isMips64EL), sb, 0),
rbi->getType(ctx.arg.isMips64EL), 0, addB, &sb});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

happy to either only pass rel.type and Symbol to TargetInfo::canFoldSection but passing Relocation sounded better to me.

Copy link
Collaborator

@smithp35 smithp35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making the patch!

It sounds like #131630 (comment) might end up with a different approach. I'll wait to see if that succeeds before commenting on the details here. There are some more relocation types we'd need to add to canFoldSection for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants