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

llvm-svn: 314862

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

llvm-svn: 314827

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: 314759

llvm-svn: 314746

Config was removed in r314719.

llvm-svn: 314736

llvm-svn: 314730

llvm-svn: 314725

llvm-svn: 314724

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

r314639 ([X86] Change register&memory TEST instructions from MRMSrcMem
to MRMDstMem) broke the test.

llvm-svn: 314645

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

llvm-svn: 314618

llvm-svn: 314617

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

This would have found the issues with r313697.

The problem was that that commit mixed the content of different
.eh_frame sections. Unfortunately we had no tests looking inside the
fdes.

llvm-svn: 314433

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