search for: inputsectionbase

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

...ages (note that characters in red are actually red on terminal): *Undefined symbols* /ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol 'lld::elf::EhFrameSection<llvm ::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld::elf::InputSectionBase*)' *Conflicting symbols* /ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:38: duplicate symbol 'lld::elf::MipsGotSection::addEntry(lld::elf::SymbolBody&, long, lld::elf::RelExpr)' /ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/SyntheticSections.cpp:673: p...

...I remember measuring that we had some very bad cache/TLB misses here, but I guess those aren't too important on the current profile (at least, not on this test case; the locality of these accesses depends a lot on the test case). Also, it seems like our performance is a lot more stable w.r.t. InputSectionBase::relocate than it used to be (or maybe my current CPU is just less affected; it's a desktop class processor instead of a xeon). I took a quick profile of this workload and it looks like it is: 65% in the writer ("backend") 30% in the "frontend" (everything called by Symbo...

...; Makes sense. I tried a few different formats based on suggestions from Mehdi, Hans and you, and come up with this one. What do you think? bin/ld.lld: *error:* undefined symbol: lld::elf::EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld::elf::InputSectionBase*) *>>> referenced by* /home/buildslave/buildslave/clang-cmake-aarch64-39vma/llvm/tools/lld/ELF/Writer.cpp:207 *>>>* lib/liblldELF.a(Writer.cpp.o) bin/ld.lld: *error:* duplicate symbol: lld::elf::MipsGotSection::addEntry(lld::elf::SymbolBody&, long, lld::elf::Re...

.../TLB misses >> here, but I guess those aren't too important on the current profile (at >> least, not on this test case; the locality of these accesses depends a lot >> on the test case). >> >> Also, it seems like our performance is a lot more stable w.r.t. >> InputSectionBase::relocate than it used to be (or maybe my current CPU is >> just less affected; it's a desktop class processor instead of a xeon). >> >> >> I took a quick profile of this workload and it looks like it is: >> >> 65% in the writer ("backend") >>...

Slowdown by "[ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do not see any reasons for any impact on perfomance by this change. Good news is that since it was NFC it can easily be reverted. But I think slowdown in results is unrelative with that change and reverting will not give us 2-3% boost back...

...unique); Config->NoUndefinedVersion = Args.hasArg(OPT_no_undefined_version); Config->NoinhibitExec = Args.hasArg(OPT_noinhibit_exec); diff --git a/ELF/InputFiles.cpp b/ELF/InputFiles.cpp index a6cd1a6..848223b 100644 --- a/ELF/InputFiles.cpp +++ b/ELF/InputFiles.cpp @@ -511,6 +511,35 @@ InputSectionBase *ObjFile<ELFT>::createInputSection(const Elf_Shdr &Sec) { if (Name == ".eh_frame" && !Config->Relocatable) return make<EhInputSection>(this, &Sec, Name); + // Profile data. + if (Name == ".note.llvm.callgraph") { + ArrayRef<uint8_...

....h" #include "llvm/Support/raw_ostream.h" #include <climits> +#include <unordered_set> using namespace llvm; using namespace llvm::ELF; @@ -922,6 +924,157 @@ static void sortBySymbolsOrder(ArrayRef<OutputSection *> OutputSections) { Sec->sort([&](InputSectionBase *S) { return SectionOrder.lookup(S); }); } +// Sort sections by the profile data provided in the .note.llvm.callgraph +// sections. +// +// This algorithm is based on Call-Chain Clustering from: +// Optimizing Function Placement for Large-Scale Data-Center Applications +// https://research.fb.co...

...R_MIPS_GOT16 and R_MIPS_CALL16 [1]. R_MIPS_GOT16 is applicable to local and external symbols and performs a different calculation in each cases [2]. R_MIPS_CALL16 is applicable to external symbols only and a linker should show an error if it finds R_MIPS_CALL16 with a local target. Now LLD in the `InputSectionBase<ELFT>::relocate` methods hides original type of GOT relocations and always use the result of `Target->getGotRefReloc()` call. In case of MIPS it is R_MIPS_GOT16. It makes impossible to perform target symbol type checking and the error generation in the `MipsTargetInfo<ELFT>::relocate...

...few different formats based on suggestions from > Mehdi, Hans and you, and come up with this one. What do you think? > > bin/ld.lld: *error:* undefined symbol: lld::elf::EhFrameSection<llvm: > :object::ELFType<(llvm::support::endianness)0, true> > >::addSection(lld::elf::InputSectionBase*) > *>>> referenced by* /home/buildslave/buildslave/cl > ang-cmake-aarch64-39vma/llvm/tools/lld/ELF/Writer.cpp:207 > *>>>* lib/liblldELF.a(Writer.cpp.o) > > > bin/ld.lld: *error:* duplicate symbol: lld::elf::MipsGotSection::addEntry(lld::elf::Symbol...

...tps://llvm.org/svn/llvm-project/lld/trunk at 263225 91177308-0d34-0410-b5e6-96231b3b80d8 r263227 ~2-3% slowdown for ScyllaDB commit 6b96b614d9e0232b106165255148af8909607ec1 Author: George Rimar <grimar at accesssoftek.com> Date: Fri Mar 11 12:57:52 2016 +0000 [ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263227 91177308-0d34-0410-b5e6-96231b3b80d8 r263228 ~6-7% slowdown for ScyllaDB commit e5aedbede69d60d90f16395af8d4fa6171a5c46a Author: Rafael Espindola <rafael.espindola at gmail.com> Date: Fri M...

...ts based on suggestions from >> Mehdi, Hans and you, and come up with this one. What do you think? >> >> bin/ld.lld: *error:* undefined symbol: lld::elf::EhFrameSection<llvm: >> :object::ELFType<(llvm::support::endianness)0, true> >> >::addSection(lld::elf::InputSectionBase*) >> *>>> referenced by* /home/buildslave/buildslave/cl >> ang-cmake-aarch64-39vma/llvm/tools/lld/ELF/Writer.cpp:207 >> *>>>* lib/liblldELF.a(Writer.cpp.o) >> >> >> bin/ld.lld: *error:* duplicate symbol: lld::elf::MipsGotSection::a...

...6 lookups. But the `MipsTargetInfo` becomes stateful. Method B keeps the `MipsTargetInfo` stateless but requires forward LO16 lookup for each HI16 relocation and requires to provide an interface for such lookup to the `MipsTargetInfo`. Sure we can implement each of these methods somewhere in the `InputSectionBase` class under `if (MIPS)` statements. Any opinions about the best method / approach? == Q2 R_MIPS_HI16 and R_MIPS_LO16 relocations perform a special calculation if a target symbol's name is `_gp_disp` [2]. AFAIK now in the target `relocateOne` method there is no chance to get the traget symbo...

...resolver. + if (Sym.isGnuIFunc() && Config->ZIfuncnoplt) + return false; + // These never do, except if the entire file is position dependent or if // only the low bits are used. if (E == R_GOT || E == R_PLT || E == R_TLSDESC) @@ -808,6 +812,10 @@ static void processRelocAux(InputSectionBase &Sec, RelExpr Expr, RelType Type, Sec.Relocations.push_back({Expr, Type, Offset, Addend, &Sym}); return; } + if (Sym.isGnuIFunc() && Config->ZIfuncnoplt) { + InX::RelaDyn->addReloc(Type, &Sec, Offset, &Sym, Addend, R_ADDEND, Type); + return; + }...

tl;dr: it looks like we call SymbolBody::getVA about 5x more times than we need to Should we cache it or something? (careful with threads). Here is a link to a PDF of my Mathematica notebook which has all the details of my investigation: https://drive.google.com/open?id=0B8v10qJ6EXRxVDQ3YnZtUlFtZ1k There seem to be two main regimes that we redundantly call SymbolBody::getVA: 1. most

...; >> Method B keeps the `MipsTargetInfo` stateless but requires forward >> LO16 lookup for each HI16 relocation and requires to provide an >> interface for such lookup to the `MipsTargetInfo`. >> >> Sure we can implement each of these methods somewhere in the >> `InputSectionBase` class under `if (MIPS)` statements. >> >> Any opinions about the best method / approach? > > > If I understand that spec correctly, an R_MIPS_HI16 should immediately be > followed by an R_MIPS_LO16. Can't you use that property? It doesn't seem to > me that you re...

...t/FileOutputBuffer.h" #include "llvm/Support/raw_ostream.h" #include <climits> +#include <unordered_set> using namespace llvm; using namespace llvm::ELF; @@ -896,6 +898,153 @@ template <class ELFT> static void sortBySymbolsOrder() { Sec->sort([&](InputSectionBase *S) { return SectionOrder.lookup(S); }); } +// Sort sections by the profile data provided in the .note.llvm.callgraph +// sections. +// +// This algorithm is based on Call-Chain Clustering from: +// Optimizing Function Placement for Large-Scale Data-Center Applications +// https://research.fb.co...

...` stateless but requires forward >> >> LO16 lookup for each HI16 relocation and requires to provide an >> >> interface for such lookup to the `MipsTargetInfo`. >> >> >> >> Sure we can implement each of these methods somewhere in the >> >> `InputSectionBase` class under `if (MIPS)` statements. >> >> >> >> Any opinions about the best method / approach? >> > >> > >> > If I understand that spec correctly, an R_MIPS_HI16 should immediately >> > be >> > followed by an R_MIPS_LO16. Can'...

On Wed, Mar 16, 2016 at 9:05 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 16 March 2016 at 01:34, George Rimar <grimar at accesssoftek.com> wrote: > > Slowdown by "[ELF] - Early continue in > InputSectionBase<ELFT>::relocate(). > > NFC." looks wierd for me. I do not see any reasons for any impact on > > perfomance by this change. > > > I think it is just because the continue is unlikely and now there is > an early check of offset. > > > Good news is that since...

...Live::markLive(), the liveness of parent sections is not propagated to the child sections. Instead, it is marked as live resulting that the section is kept even though the parent section is removed. To fix this issue, I propose changing the code marking sections live to the following loop: for (InputSectionBase *Sec : InputSections) {     if (Sec->Flags & SHF_LINK_ORDER)         Sec->Live = Sec->getLinkOrderDep()->Live;     else {         bool IsAlloc = (Sec->Flags & SHF_ALLOC);         bool IsRel = (Sec->Type == SHT_REL || Sec->Type == SHT_RELA);         if (!IsAlloc &a...