We no longer call reserveSpace more than once, so it can be merged with
its constructor.

llvm-svn: 314867

When reporting a symbol conflict, LLD parses the debug info to report
source location information. Sections have not been decompressed at this
point, so if an object file contains zlib compressed debug info, LLD
ends up passing this compressed debug info to the DWARF parser, which
causes debug info parsing failures and can trigger assertions in the
parser (as the test case demonstrates).

Decompress debug sections when constructing the LLDDwarfObj to avoid
this issue. This doesn't handle GNU-style compressed debug info sections
(.zdebug_*), which at present are simply ignored by LLDDwarfObj; those
can be done in a follow-up.

Differential Revision: https://reviews.llvm.org/D38491

llvm-svn: 314866

We have this comment in LinkerDriver::link

  After this, no new names except a few linker-synthesized ones
  will be added to the symbol table.

but that was not true because new symbols could be added by processing
the -u option.

llvm-svn: 314842

llvm-svn: 314841

The issue with std::thread::hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.

With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.

This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.

llvm-svn: 314810

If symbol has the STO_MIPS_MICROMIPS flag and requires a thunk to perform
call PIC from non-PIC functions, we need to generate a thunk with microMIPS
code.

llvm-svn: 314797

Without this patch, lld emits "error: undefined symbol: _start"
if it encountered only weak references to that symbol.

llvm-svn: 314790

Differential Revision: https://reviews.llvm.org/D38348

llvm-svn: 314789

llvm-svn: 314746

Config was removed in r314719.

llvm-svn: 314736

New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.

Differential Revision: https://reviews.llvm.org/D37645

llvm-svn: 314719

Reads from `Live` and writes to `OutputOff` in the following code race
even though they are logically independent because they are bitfields
sharing the same word.

  for (size_t I = 0, E = Sec->Pieces.size(); I != E; ++I) {
    if (!Sec->Pieces[I].Live)
      continue;
    CachedHashStringRef Str = Sec->getData(I);
    size_t ShardId = getShardId(Str.hash());
    if ((ShardId & (Concurrency - 1)) == ThreadId)
      Sec->Pieces[I].OutputOff = Shards[ShardId].add(Str);
  }

llvm-svn: 314711

llvm-svn: 314707

Currently LLD calls the `isMicroMips` routine to determine type of PLT entries
needs to be generated: regular or microMIPS. This routine checks ELF
header flags in the `FirstObj` to retrieve type of linked object files.
So if the first file does not contain microMIPS code, LLD will generate
PLT entries with regular (non-microMIPS) code only.

Ideally, if a PLT entry is referenced by microMIPS code only this entry
should contain microMIPS code, if a PLT entry is referenced by regular
code this entry should contain regular code. In a "mixed" case the PLT
entry can be either microMIPS or regular, but each "cross-mode-call" has
additional cost.

It's rather difficult to implement this ideal solution. But we can
assume that if there is an input object file with microMIPS code, the
most part of the code is microMIPS too. So we need to deduce type of PLT
entries based on finally calculated ELF header flags and do not check
only the first input object file.

This change implements this.
  - The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function
    called from the `LinkerDriver::link`. Result is stored in
    the Configuration::MipsEFlags field.
  - The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags`
    field to get and check calculated ELF flags.
  - New types of PLT records created when necessary.

Differential revision: https://reviews.llvm.org/D37747

llvm-svn: 314675

That makes code a bit more consistent. Instead of removing sections there
we can just mark them as dead. So that removeEmptyCommands() will
handle the rest.

Differential revision: https://reviews.llvm.org/D38393

llvm-svn: 314654

Computing section content hashes early seems like a win in terms of
performance. It increases a chance that two different sections will get
different class IDs from the beginning.

Without threads, this patch improves Chromium link time by about 0.3
seconds. With threads, by 0.1 seconds. That's less than 1% time saving
but not bad for a small patch.

llvm-svn: 314644

llvm-svn: 314637

I don't know why we didn't use parallelForEach to call writeTo,
but there should be no reason to not do that, as most writeTo
functions are safe to run concurrently.

llvm-svn: 314616

The result of hash_value(StringRef) depends on sizeof(size_t).
That causes lld to create different mergeable table contents on
32-bit machines.

This patch is to use xxHash64 so that we get the same hash values
on 32-bit machines.

llvm-svn: 314603

llvm-svn: 314592

llvm-svn: 314591

llvm-svn: 314590

String merging is one of the most time-consuming functions in lld.
This patch parallelize it to speed it up. On my 2-socket 20-core
40-threads Xeon E5-2680 @ 2.8 GHz machine, this patch shorten the
clang debug build link time from 7.11s to 5.16s. It's a 27%
improvement and actually pretty noticeable. In this test condition,
lld is now 4x faster than gold.

Differential Revision: https://reviews.llvm.org/D38266

llvm-svn: 314588

llvm-svn: 314496

Convert all common symbols to regular symbols after scan.
This means that the downstream code does not to handle common symbols as a special case.

Differential Revision: https://reviews.llvm.org/D38137

llvm-svn: 314495

We were not subtracting its size, causing it to overlap with section
data.

Fixes PR34750.

llvm-svn: 314440

llvm-svn: 314394

As suggested in review comments of D38170.

llvm-svn: 314392

Detemplation of one more synthetic section.

Differential revision: https://reviews.llvm.org/D38241

llvm-svn: 314283

This is "Bug 34688 - lld much slower than bfd when linking the linux kernel"

Inside copyRelocations() we have O(N*M) algorithm, where N - amount of
relocations and M - amount of symbols in symbol table. It isincredibly slow
for linking linux kernel.

Patch creates local search tables to speedup.
With this fix link time goes for me from 12.95s to 0.55s what is almost 23x
faster. (used release LLD).

Differential revision: https://reviews.llvm.org/D38129

llvm-svn: 314282

SymbolTable::insert() is a hot path function. When linking a clang debug
build, the function is called 3.7 million times. The total amount of "Name"
string contents is 300 MiB. That means this `Name.find("@@")` scans almost
300 MiB of data. That's far from negligible.

StringRef::find(StringRef) uses a sophisticated algorithm, but the
function is slow for a short needle. This patch replaces it with
StringRef::find(char).

This patch alone speeds up a clang debug build link time by 0.5 seconds
from 8.2s to 7.7s. That's 6% speed up. It seems too good for this tiny
change, but looks like it's real.

llvm-svn: 314192

This patch alone is neutral in terms of code readability, but this
change makes a following patch easier to read.

llvm-svn: 314181

llvm-svn: 314126

llvm-svn: 314120

[Synopsys]
Using function elf::link(...) leads to segmentation fault on its second call. First call finishes correctly.
[Solution]
Clear the rest of globals.

Reviewed by: George Rimar and Rui Ueyama

Differential Revision: http://reviews.llvm.org/D38131

llvm-svn: 314108

Previously`InX::Got` and InX::MipsGot synthetic sections
were not removed if ElfSym::GlobalOffsetTable was defined.
ElfSym::GlobalOffsetTable is a symbol for _GLOBAL_OFFSET_TABLE_.

Patch moves ElfSym::GlobalOffsetTable check out from removeUnusedSyntheticSections.
Also note that there was no point to check ElfSym::GlobalOffsetTable for MIPS case
because InX::MipsGot::empty() always returns false for non-relocatable case, and in case
of relocatable output we do not create special symbols anyways.

Differential revision: https://reviews.llvm.org/D37623

llvm-svn: 314099

When -verbose is specified, patch outputs names of each input orphan section
assigned to output.

Differential revision: https://reviews.llvm.org/D37517

llvm-svn: 314098

Previously when BC file had global variable that was accessed from script,
it was optimized away or inlined by IPO. 
In this patch I add symbols at left side of assignment expression as LinkerRedefined,
what prevents optimization for them.

Differential revision: https://reviews.llvm.org/D37059

llvm-svn: 314097

We used to sort and uniquify CU vectors, but looks like CU vectors in
.gdb_index sections created by gold are not guaranteed to be sorted.

llvm-svn: 314095

We used to use std::set to uniquify CU vector elements, but as we know,
std::set is pretty slow. Fortunately we didn't actually have to use a
std::set here. This patch replaces it with std::vector.

With this patch, lld's -gdb-index overhead when linking a clang debug
build is now about 1 second (8.65 seconds without -gdb-index vs 9.60
seconds with -gdb-index). Since gold takes more than 6 seconds to create
a .gdb_index for the same output, our number isn't that bad.

llvm-svn: 314094