Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
  need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
    
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
  the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
  first caller to the Thunk.
    
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.

This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.

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

llvm-svn: 293757

This reverts commit r293283 because it broke MSVC build.

llvm-svn: 293352

    
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
  need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
    
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
  the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
  first caller to the Thunk.
    
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.

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

llvm-svn: 293283

    
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
    
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.

llvm-svn: 290951

llvm-svn: 287967

Previously, we have a lot of BumpPtrAllocators, but all these
allocators virtually have the same lifetime because they are
not freed until the linker finishes its job. This patch aggregates
them into a single allocator.

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

llvm-svn: 285452

We used to have one allocator per file, which reduces the advantage of
using an allocator in the first place.

This is a small speed up is most cases. The largest speedup was in
1.014X in chromium no-gc. The largest slowdown was scylla at 1.003X.

llvm-svn: 285205

llvm-svn: 282798

llvm-svn: 282670

llvm-svn: 282668

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

llvm-svn: 282656

Previously, all input files were owned by the symbol table.
Files were created at various places, such as the Driver, the lazy
symbols, or the bitcode compiler, and the ownership of new files
was transferred to the symbol table using std::unique_ptr.
All input files were then free'd when the symbol table is freed
which is on program exit.

I think we don't have to transfer ownership just to free all
instance at once on exit.

In this patch, all instances are automatically collected to a
vector and freed on exit. In this way, we no longer have to
use std::unique_ptr.

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

llvm-svn: 281425

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

llvm-svn: 275526

This fixes PR28218. Thanks to Rafael for spotting a failure in
the SHARED_LIBS build!

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

llvm-svn: 273451

llvm-svn: 267935

Using multiple context used to be a really big memory saving because we
could free memory from each file while the linker proceeded with the
symbol resolution. We are getting lazier about reading data from the
bitcode, so I was curious if this was still a good tradeoff.

One thing that is a bit annoying is that we still have to copy the
symbol names. The problem is that the names are stored in the Module and
get freed when we move the module bits during linking.

Long term I think the solution is to add a symbol table to the bitcode.
That way IRObject file will not need to use a Module or a Context and we
can drop it while still keeping a StringRef to the names.

This patch is still be an interesting medium term improvement.

When linking llvm-as without debug info this patch is a small speedup:

master: 29.861877513 seconds
patch: 29.814533787 seconds

With debug info the numbers are

master: 34.765181469 seconds
patch: 34.563351584 seconds

The peak memory usage when linking llvm-as with debug info was

master: 599.10MB
patch: 600.13MB
llvm-svn: 267921

llvm-svn: 267222

llvm-svn: 267221

This is not on by default (but it might be in the future).
The knob to enable the optimization is -lto-discard-value-names.

llvm-svn: 266953

llvm-svn: 266714

It is a pity that we have to create a TargetMachine once per thread,
so at least make that code as small as possible.

llvm-svn: 266578

Make sure lld enables ODR type uniquing for debug info when invoking
LTO, as a follow-up to LLVM r266549.

llvm-svn: 266555

Parallelism level can be chosen using the new --lto-jobs=K option
where K is the number of threads used for CodeGen. It currently
defaults to 1.

llvm-svn: 266484

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

llvm-svn: 266009

llvm-svn: 264770

IPO doesn't work very well across symbols referenced
by others TUs. The linker here tries to evaluate
which symbols are safe to internalize and switches
their linkage.

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

llvm-svn: 264585

http://reviews.llvm.org/D18410

llvm-svn: 264193

The code for LTO has been growing, so now is probably a good time to
move it to its own file. SymbolTable.cpp is for symbol table, and
because compiling bitcode files are semantically not a part of
symbol table, this is I think a good thing to do.

http://reviews.llvm.org/D18370

llvm-svn: 264091