llvmbot wrote:
<!--LLVM PR SUMMARY COMMENT--> @llvm/pr-subscribers-lld Author: Peter Collingbourne (pcc) <details> <summary>Changes</summary> This lock is unnecessary because we can add the relocations to shards and let them be sorted later. --- Full diff: https://github.com/llvm/llvm-project/pull/135123.diff 1 Files Affected: - (modified) lld/ELF/Relocations.cpp (+2-3) ``````````diff diff --git a/lld/ELF/Relocations.cpp b/lld/ELF/Relocations.cpp index 81de664fd1c23..277acb26987bc 100644 --- a/lld/ELF/Relocations.cpp +++ b/lld/ELF/Relocations.cpp @@ -847,9 +847,8 @@ static void addRelativeReloc(Ctx &ctx, InputSectionBase &isec, Partition &part = isec.getPartition(ctx); if (sym.isTagged()) { - std::lock_guard<std::mutex> lock(ctx.relocMutex); - part.relaDyn->addRelativeReloc(ctx.target->relativeRel, isec, offsetInSec, - sym, addend, type, expr); + 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 `````````` </details> https://github.com/llvm/llvm-project/pull/135123 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
