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
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
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
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
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
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
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
Rui Ueyama