summaryrefslogtreecommitdiffstats
path: root/lld/ELF/LTO.h
Commit message (Collapse)AuthorAgeFilesLines
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | letter This patch is mechanically generated by clang-llvm-rename tool that I wrote using Clang Refactoring Engine just for creating this patch. You can see the source code of the tool at https://reviews.llvm.org/D64123. There's no manual post-processing; you can generate the same patch by re-running the tool against lld's code base. Here is the main discussion thread to change the LLVM coding style: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html In the discussion thread, I proposed we use lld as a testbed for variable naming scheme change, and this patch does that. I chose to rename variables so that they are in camelCase, just because that is a minimal change to make variables to start with a lowercase letter. Note to downstream patch maintainers: if you are maintaining a downstream lld repo, just rebasing ahead of this commit would cause massive merge conflicts because this patch essentially changes every line in the lld subdirectory. But there's a remedy. clang-llvm-rename tool is a batch tool, so you can rename variables in your downstream repo with the tool. Given that, here is how to rebase your repo to a commit after the mass renaming: 1. rebase to the commit just before the mass variable renaming, 2. apply the tool to your downstream repo to mass-rename variables locally, and 3. rebase again to the head. Most changes made by the tool should be identical for a downstream repo and for the head, so at the step 3, almost all changes should be merged and disappear. I'd expect that there would be some lines that you need to merge by hand, but that shouldn't be too many. Differential Revision: https://reviews.llvm.org/D64121 llvm-svn: 365595
* [ELF] Reorder BitcodeFiles.empty() to call thinLTOCreateEmptyIndexFiles() in ↵Fangrui Song2019-05-071-2/+0
| | | | | | | | | | | | | | | | | only one place It makes the --plugin-opt=obj-path= and --plugin-opt=thinlto-index-only= behavior more consistent - the files will be created in the BitcodeFiles.empty() case, but I assume whether it behaves this way is not required by anyone. LTOObj->run() cannot run with empty BitcodeFiles. There would be an error: ld.lld: error: No available targets are compatible with triple "" Differential Revision: https://reviews.llvm.org/D61635 llvm-svn: 360129
* [ELF] --plugin-opt=thinlto-index-only: create empty index files even if all ↵Fangrui Song2019-05-021-0/+2
| | | | | | | | | | | | | | | | | | | bitcode files are lazy Summary: The gold plugin behavior (creating empty index files for lazy bitcode files) was added in D46034, but it missed the case when there is no non-lazy bitcode files, e.g. ld.lld -shared crti.o crtbeginS.o --start-lib bitcode.o --end-lib ... crti.o crtbeginS.o are not bitcode, but our distributed build system wants bitcode.o.thinlto.bc to confirm all expected outputs are created based on all of the modules provided to the linker. Differential Revision: https://reviews.llvm.org/D61420 llvm-svn: 359788
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Simplify.Rui Ueyama2018-09-111-1/+1
| | | | | | Instead of Map<StringRef, bool>, we can simply use Set<StringRef>. llvm-svn: 341948
* Improve error message for -thinlto-object-suffix-replace and simplify code.Rui Ueyama2018-05-171-1/+1
| | | | llvm-svn: 332643
* Update ThinLTO Indexing logicRumeet Dhindsa2018-05-081-0/+1
| | | | | | | | Instead of writing empty index for file, this patch tracks the state of files in ObjectToIndexFileState. If the files are not indexed , only then we emit the empty files Differential Revision: https://reviews.llvm.org/D46480 llvm-svn: 331803
* Split BitcodeCompiler::init() into two functions. NFC.Rui Ueyama2018-05-071-2/+0
| | | | | | | | | Previously, code to initialize Backend and code to initialize Conf are intermingled in init(), though they don't depend on each other. Differential Revision: https://reviews.llvm.org/D46554 llvm-svn: 331698
* Refactor ThinLTO-related code in BitcodeCompiler.cpp. NFC.Rui Ueyama2018-05-071-1/+0
| | | | | | | | | | | | Summary: Refactor ThinLTO-related code in BitcodeCompiler.cpp. NFC. Reviewers: rdhindsa, espindola Subscribers: emaste, inglorion, arichardson, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D46549 llvm-svn: 331689
* Refactor BitcodeCompiler::createLTO. NFC.Rui Ueyama2018-05-071-1/+3
| | | | llvm-svn: 331655
* Added support for ThinLTO plugin options : thinlto-index-only and ↵Rumeet Dhindsa2018-05-021-0/+4
| | | | | | | | thinlto-prefix-replace Differential Revision: https://reviews.llvm.org/D46034 llvm-svn: 331405
* Move new lld's code to Common subdirectory.Rui Ueyama2017-10-021-1/+1
| | | | | | | | | | 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
* Make __start_sec __end_sec handling more precise.Rafael Espindola2017-07-261-0/+2
| | | | | | | | | | With this we only ask LTO to keep a C named section if there is a __start_ or __end symbol. This is not as strict as lld's --gc-sections, but is as good as we can get without having a far more detailed ir summary. llvm-svn: 309232
* [ELF] - Apply clang-format. NFC.George Rimar2017-07-181-3/+3
| | | | llvm-svn: 308297
* ELF: Add ThinLTO caching support.Peter Collingbourne2017-03-011-0/+1
| | | | | | | | | | This patch adds an option named --thinlto-cache-dir, which specifies the path to a directory in which to cache native object files for ThinLTO incremental builds. Differential Revision: https://reviews.llvm.org/D30509 llvm-svn: 296702
* [ELF] Use SyntheticSections for ThunksPeter Smith2017-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[ELF][ARM] Use SyntheticSections for Thunks"Rui Ueyama2017-01-281-1/+1
| | | | | | This reverts commit r293283 because it broke MSVC build. llvm-svn: 293352
* [ELF][ARM] Use SyntheticSections for ThunksPeter Smith2017-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Add support for thunks to undefined non-weak symbolsPeter Smith2017-01-041-1/+1
| | | | | | | | | | | | 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
* [ELF] Be compliant with LLVM and rename Lto into LTO. NFCI.Davide Italiano2016-11-261-1/+1
| | | | llvm-svn: 287967
* Consolidate BumpPtrAllocators.Rui Ueyama2016-10-281-1/+0
| | | | | | | | | | | 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
* Reduce the number of allocators.Rafael Espindola2016-10-261-0/+1
| | | | | | | | | | 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
* Keep a private member private.Rui Ueyama2016-09-291-2/+2
| | | | llvm-svn: 282798
* Attempt to fix Windows buildbots.Rui Ueyama2016-09-291-0/+2
| | | | llvm-svn: 282670
* Remove unused #includes.Rui Ueyama2016-09-291-3/+0
| | | | llvm-svn: 282668
* [ELF/LTO] Switch to the new resolution-based API.Davide Italiano2016-09-291-7/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D24492 llvm-svn: 282656
* Simplify InputFile ownership management.Rui Ueyama2016-09-141-2/+2
| | | | | | | | | | | | | | | | | | | | 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
* ELF: Remove member variables that are used only in one function.Rui Ueyama2016-07-151-2/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D22396 llvm-svn: 275526
* [LTO] Include ASM undefs in llvm.compiler_used.Davide Italiano2016-06-221-0/+1
| | | | | | | | | 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
* Delete dead variable.Rafael Espindola2016-04-281-1/+0
| | | | llvm-svn: 267935
* Use a single context for lto.Rafael Espindola2016-04-281-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove unused #include.Rui Ueyama2016-04-221-1/+0
| | | | llvm-svn: 267222
* Move BitcodeCompiler constructor to the .cpp file. NFC.Rui Ueyama2016-04-221-6/+1
| | | | llvm-svn: 267221
* [LTO] Discard names for Values that are not global.Davide Italiano2016-04-211-0/+2
| | | | | | | 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
* LTO: Adapt to LLVM API changes in r266713Duncan P. N. Exon Smith2016-04-191-1/+1
| | | | llvm-svn: 266714
* Make CreateTargetMachine as small as possible.Rafael Espindola2016-04-171-2/+2
| | | | | | | 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
* LTO: Merge debug info types when linking bitcodeDuncan P. N. Exon Smith2016-04-171-1/+3
| | | | | | | Make sure lld enables ODR type uniquing for debug info when invoking LTO, as a follow-up to LLVM r266549. llvm-svn: 266555
* [LTO] Implement parallel Codegen for LTO using splitCodeGen.Davide Italiano2016-04-151-3/+5
| | | | | | | | 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
* [LTO] Switch Module to std::unique_ptr<>.Davide Italiano2016-04-111-2/+5
| | | | | | Differential Revision: http://reviews.llvm.org/D18994 llvm-svn: 266009
* Make BitcodeCompiler::compile a non-template function. NFC.Rui Ueyama2016-03-291-2/+2
| | | | llvm-svn: 264770
* [LTO] Internalize symbols.Davide Italiano2016-03-281-0/+2
| | | | | | | | | | | 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
* ELF: Split BitcodeCompiler::compile.Rui Ueyama2016-03-231-0/+2
| | | | | | http://reviews.llvm.org/D18410 llvm-svn: 264193
* ELF: Create LTO.{cpp,h} and move LTO-related code to that file.Rui Ueyama2016-03-221-0/+51
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
OpenPOWER on IntegriCloud