| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 275512
|
|
|
|
|
|
| |
This new name is also consistent with ELF.
llvm-svn: 275500
|
|
|
|
| |
llvm-svn: 275480
|
|
|
|
| |
llvm-svn: 270907
|
|
|
|
| |
llvm-svn: 266375
|
|
|
|
|
|
|
|
| |
This reverts commit r266365 and r266367, the contexts in the two
places have to match.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266373
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266365
|
|
|
|
|
|
| |
Suggested by: David Blaikie!
llvm-svn: 266140
|
|
|
|
|
|
| |
This way we're consistent between ELF and COFF.
llvm-svn: 265885
|
|
|
|
| |
llvm-svn: 254697
|
|
|
|
|
|
|
|
| |
This should help reduce memory consumption during LTO.
Differential Revision: http://reviews.llvm.org/D14672
llvm-svn: 253397
|
|
|
|
| |
llvm-svn: 253374
|
|
|
|
|
|
| |
disabled.
llvm-svn: 248193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, InputFile::parse() was run in batch. We construct a list
of all input files and call parse() on each file using parallel_for_each.
That means we cannot start parsing files until we get a complete list
of input files, although InputFile::parse() is safe to call from anywhere.
This patch makes it asynchronous. As soon as we add a file to the symbol
table, we now start parsing the file using std::async().
This change shortens self-hosting time (650 ms) by 28 ms. It's about 4%
improvement.
llvm-svn: 248109
|
|
|
|
|
|
|
|
| |
I made the field an atomic pointer in hope that we would be able to
parallelize the symbol resolver soon, but that's not going to happen
soon. This patch reverts that change for the sake of readability.
llvm-svn: 248104
|
|
|
|
|
|
| |
This is a follow-up patch to r248078.
llvm-svn: 248098
|
|
|
|
| |
llvm-svn: 248081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InputFile::parse() can be called in parallel with other calls of
the same function. By doing that, time to self-link improves from
741 ms to 654 ms or 12% faster.
This is probably the last low hanging fruit in terms of parallelism.
Input file parsing and symbol table insertion takes 450 ms in total.
If we want to optimize further, we probably have to parallelize
symbol table insertion using concurrent hashmap or something.
That's doable, but that's not easy, especially if you want to keep
the exact same semantics and linking order. I'm not going to do that
at least soon.
Anyway, compared to r248019 (the change before the first attempt for
parallelism), we achieved 36% performance improvement from 1022 ms
to 654 ms. MSVC linker takes 3.3 seconds to link the same program.
MSVC's ICF feature is very slow for some reason, but even if we
disable the feature, it still takes about 1.2 seconds.
Our number is probably good enough.
llvm-svn: 248078
|
|
|
|
| |
llvm-svn: 247956
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically the concept of "liveness" is for sections (or chunks in LLD
terminology) and not for symbols. Symbols are always available or live,
or otherwise it indicates a link failure.
Previously, we had isLive() and markLive() methods for DefinedSymbol.
They are confusing methods. What they actually did is to act as a proxy
to backing section chunks. We can simplify eliminate these methods
and call section chunk's methods directly.
llvm-svn: 247869
|
|
|
|
|
|
|
| |
Perhaps lld wants to disable the verifier sometimes during COFF LTO, but
for now just match behaviour from before r247735.
llvm-svn: 247736
|
|
|
|
| |
llvm-svn: 246662
|
|
|
|
|
|
|
|
|
| |
This is exposed via a new flag /opt:lldltojobs=N, where N is the number of
code generation threads.
Differential Revision: http://reviews.llvm.org/D12309
llvm-svn: 246342
|
|
|
|
| |
llvm-svn: 245892
|
|
|
|
|
|
| |
isLive returns false if it's not COMDAT, so check for that condition.
llvm-svn: 245676
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12024
llvm-svn: 245027
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has a few advantages
* Less C++ code (about 300 lines less).
* Less machine code (about 14 KB of text on a linux x86_64 build).
* It is more debugger friendly. Just set a breakpoint on the exit function and
you get the complete lld stack trace of when the error was found.
* It is a more robust API. The errors are handled early and we don't get a
std::error_code hot potato being passed around.
* In most cases the error function in a better position to print diagnostics
(it has more context).
llvm-svn: 244215
|
|
|
|
| |
llvm-svn: 243495
|
|
|
|
| |
llvm-svn: 243229
|
|
|
|
|
|
|
|
| |
In many places we assumed that is64() means AMD64 and i386 otherwise.
This assumption is not sound because Windows also supports ARM.
The linker doesn't support ARM yet, but this is a first step.
llvm-svn: 243188
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An object file compatible with Safe SEH contains a .sxdata section.
The section contains a list of symbol table indices, each of which
is an exception handler function. A safe SEH-enabled executable
contains a list of exception handler RVAs. So, what the linker has
to do to support Safe SEH is basically to read the .sxdata section,
interpret the contents as a list of symbol indices, unique-fy and
sort their RVAs, and then emit that list to .rdata. This patch
implements that feature.
llvm-svn: 243182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__ImageBase is a special symbol whose value is the image base address.
Previously, we handled __ImageBase symbol as an absolute symbol.
Absolute symbols point to specific locations in memory and the locations
never change even if an image is base-relocated. That means that we
don't have base relocation entries for absolute symbols.
This is not a case for __ImageBase. If an image is base-relocated, its
base address changes, and __ImageBase needs to be shifted as well.
So we have to have base relocations for __ImageBase. That means that
__ImageBase is not really an absolute symbol but a different kind of
symbol.
In this patch, I introduced a new type of symbol -- DefinedRelative.
DefinedRelative is similar to DefinedAbsolute, but it has not a VA but RVA
and is a subject of base relocation. Currently only __ImageBase is of
the new symbol type.
llvm-svn: 243176
|
|
|
|
|
|
|
|
|
|
|
| |
Entry name selection rule is already complicated on x64, but it's more
complicated on x86 because of the underscore name mangling scheme.
If one of _main, _main@<number> (a C function) or ?main@@... (a C++ function)
is defined, entry name is _mainCRTStartup. If _wmain, _wmain@<number or
?wmain@@... is defined, entry name is _wmainCRTStartup. And so on.
llvm-svn: 242110
|
|
|
|
|
|
|
|
| |
Symbol foo is mangled as _foo in C and ?foo@@... in C++ on x86.
findMangle has to remove prefix underscore before mangle a given name
as a C++ symbol.
llvm-svn: 241874
|
|
|
|
|
|
|
|
| |
We now report the names of any files containing undefined symbol references.
Differential Revision: http://reviews.llvm.org/D10982
llvm-svn: 241612
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were unnecessarily loading lazy symbols if they appeared in an
archive multiple times, as can happen with comdat symbols. This change fixes
the bug by only loading symbols from archives at load time if the original
symbol was undefined.
Differential Revision: http://reviews.llvm.org/D10980
llvm-svn: 241538
|
|
|
|
| |
llvm-svn: 241477
|
|
|
|
|
|
|
| |
Note that the linker is not multi-threaded yet.
This is a preparation for that.
llvm-svn: 241417
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the new design, mutation of Symbol pointers is the name resolution
operation. This patch makes them atomic pointers so that they can
be mutated by multiple threads safely. I'm going to use atomic
compare-exchange on these pointers.
dyn_cast<> doesn't recognize atomic pointers as pointers,
so we need to call load(). This is unfortunate, but in other places
automatic type conversion works fine.
llvm-svn: 241416
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were previously hitting assertion failures in the writer in cases where
a regular object file defined a weak external symbol that was defined by
a bitcode file. Because /export and /entry name mangling were implemented
using weak externals, the same problem affected mangled symbol names in
bitcode files.
The underlying cause of the problem was that weak external symbols were
being resolved before doing LTO, so the symbol table may have contained stale
references to bitcode symbols. The fix here is to defer weak external symbol
resolution until after LTO.
Also implement support for weak external symbols in bitcode files
by modelling them as replaceable DefinedBitcode symbols.
Differential Revision: http://reviews.llvm.org/D10940
llvm-svn: 241391
|
|
|
|
| |
llvm-svn: 241384
|
|
|
|
|
|
|
|
|
|
| |
This worked before, but only by accident, and only with assertions disabled.
We ended up storing a DefinedRegular symbol in the WeakAlias field,
and never using it as an Undefined.
Differential Revision: http://reviews.llvm.org/D10934
llvm-svn: 241376
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, __ImageBase symbol got a different value than the one
specified by /base:<number> because the symbol was created in the
SymbolTable's constructor. When the constructor is called,
no command line options are processed yet, so the symbol was
created always with the initial value. This caused wrong relocations
and thus caused mysterious crashes of some executables linked by LLD.
llvm-svn: 241313
|
|
|
|
| |
llvm-svn: 241311
|
|
|
|
| |
llvm-svn: 241238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, we have four different main functions, {w,}{main,WinMain}.
The linker has to choose a corresponding entry point function among
{w,}{main,WinMain}CRTStartup. These entry point functions are defined
in the standard library. The linker resolves one of them by looking at
which main function is defined and adding a corresponding undefined
symbol to the symbol table.
Object files containing entry point functions conflicts each other.
For example, we cannot resolve both mainCRTStartup and WinMainCRTStartup
because other symbols defined in the files conflict.
Previously, we inferred CRT function name at the very end of name
resolution. I found that that is sometimes too late. If the linker
already linked one of these four archive member objects, it's too late
to change the decision.
The right thing to do here is to infer entry point name after adding
all symbols from command line files and before adding any other files
(which are specified by directive sections). This patch does that.
llvm-svn: 241236
|
|
|
|
|
|
|
|
| |
Previously, we use SymbolTable::rename to resolve AlternateName symbols.
This patch is to merge that mechanism with weak aliases, so that we
remove that function.
llvm-svn: 241230
|
|
|
|
|
|
| |
The previous name was too long to my taste.
llvm-svn: 241215
|
|
|
|
|
|
|
|
|
| |
I think Undefined symbols are a bit more convenient than StringRefs
since SymbolBodies are handles for symbols. You can get resolved
symbols for undefined symbols just by calling getReplacmenet without
looking up the symbol table.
llvm-svn: 241214
|
|
|
|
|
|
|
|
|
|
| |
Occasionally we have to resolve an undefined symbol to its
mangled symbol. Previously, we did that on calling side of
findMangle by explicitly updating SymbolBody.
In this patch, mangled symbols are handled as weak aliases
for undefined symbols.
llvm-svn: 241213
|