summaryrefslogtreecommitdiffstats
path: root/llvm/tools/lto
Commit message (Collapse)AuthorAgeFilesLines
...
* Switch lto codegen to using diagnostic handlers.Yunzhong Gao2015-11-171-5/+5
| | | | | | | | | | | This patch removes the std::string& argument from a number of C++ LTO API calls and instead makes them use the installed diagnostic handler. This would also improve consistency of diagnostic handling infrastructure: if an LTO client used lto_codegen_set_diagnostic_handler() to install a custom error handler, we do not want some error messages to go through the custom error handler, and some other error messages to go into sLastErrorString. llvm-svn: 253367
* Add a libLTO diagnostic handler that supports lto_get_error_message APIYunzhong Gao2015-11-111-2/+10
| | | | | | | | | | | | | | This is a follow-up from the previous discussion on the thread: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307763.html The LibLTO lto_get_error_message() API reads error messages from a std::string sLastErrorString. Instead of passing this string around as an argument, this patch creates a diagnostic handler and then sends this handler to the constructor of LTOCodeGenerator. Differential Revision: http://reviews.llvm.org/D14313 llvm-svn: 252791
* [CMake] Add LLVM_VERSION_PATCH to the -current_version flag for libLTO and ↵Chris Bieneman2015-10-141-1/+1
| | | | | | | | libLLVM. This is to match autoconf where LLVM_SUBMIT_SUBVERSION is usually set to ${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}. llvm-svn: 250277
* [CMake] Add compatibility and current versioning to libLTO to match autoconf ↵Chris Bieneman2015-10-131-0/+10
| | | | | | | | support. This also adds LLVM_LTO_VERSION_OFFSET to support functional equivalence to autoconf. llvm-svn: 250245
* Reapply "LTO: Disable extra verify runs in release builds"Duncan P. N. Exon Smith2015-09-151-6/+16
| | | | | | | This reverts commit r247730, effectively reapplying r247729. This time I have an lld commit ready to follow. llvm-svn: 247735
* Revert "LTO: Disable extra verify runs in release builds"Duncan P. N. Exon Smith2015-09-151-16/+6
| | | | | | | This temporarily reverts commit r247729, as it caused lld build failures. I'll recommit once I have an lld patch ready-to-go. llvm-svn: 247730
* LTO: Disable extra verify runs in release buildsDuncan P. N. Exon Smith2015-09-151-6/+16
| | | | | | | | | | | | | | | | | | | | | | The verifier currently runs three times in LTO: (1) after parsing, (2) at the beginning of the optimization pipeline, and (3) at the end of it. The first run is important, since we're not sure where the bitcode comes from and it's nice to validate it, but in release builds the extra runs aren't appropriate. This commit: - Allows these runs to be disabled in LTOCodeGenerator. - Adds command-line options to llvm-lto. - Adds command-line options to libLTO.dylib, and disables the verifier by default in release builds (based on NDEBUG). This shaves about 3.5% off the runtime of ld64 when linking verify-uselistorder with -flto -g. rdar://22509081 llvm-svn: 247729
* LTO: Simplify merged module ownership.Peter Collingbourne2015-08-241-1/+1
| | | | | | | | | | | This change moves LTOCodeGenerator's ownership of the merged module to a field of type std::unique_ptr<Module>. This helps simplify parts of the code and clears the way for the module to be consumed by LLVM CodeGen (see D12132 review comments). Differential Revision: http://reviews.llvm.org/D12205 llvm-svn: 245891
* LTO: Change signature of LTOCodeGenerator::setCodePICModel() to take a ↵Peter Collingbourne2015-08-211-2/+16
| | | | | | | | | Reloc::Model. This allows us to remove a bunch of code in LTOCodeGenerator and llvm-lto and has the side effect of improving error handling in the libLTO C API. llvm-svn: 245756
* lto: Clean up C libLTO interfaces pertaining to linker flags.Peter Collingbourne2015-06-292-19/+2
| | | | | | | | | Specifically, remove the dependent library interface and replace the existing linker option interface with a new one that returns a single list of flags. Differential Revision: http://reviews.llvm.org/D10820 llvm-svn: 241018
* Teach LTOModule to emit linker flags for dllexported symbols, plus interface ↵Peter Collingbourne2015-06-291-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cleanup. This change unifies how LTOModule and the backend obtain linker flags for globals: via a new TargetLoweringObjectFile member function named emitLinkerFlagsForGlobal. A new function LTOModule::getLinkerOpts() returns the list of linker flags as a single concatenated string. This change affects the C libLTO API: the function lto_module_get_*deplibs now exposes an empty list, and lto_module_get_*linkeropts exposes a single element which combines the contents of all observed flags. libLTO should never have tried to parse the linker flags; it is the linker's job to do so. Because linkers will need to be able to parse flags in regular object files, it makes little sense for libLTO to have a redundant mechanism for doing so. The new API is compatible with the old one. It is valid for a user to specify multiple linker flags in a single pragma directive like this: #pragma comment(linker, "/defaultlib:foo /defaultlib:bar") The previous implementation would not have exposed either flag via lto_module_get_*deplibs (as the test in TargetLoweringObjectFileCOFF::getDepLibFromLinkerOpt was case sensitive) and would have exposed "/defaultlib:foo /defaultlib:bar" as a single flag via lto_module_get_*linkeropts. This may have been a bug in the implementation, but it does give us a chance to fix the interface. Differential Revision: http://reviews.llvm.org/D10548 llvm-svn: 241010
* Adding the missing LTO API to lto.exportsSteven Wu2015-06-231-0/+1
| | | | | | | | | | | | | | Summary: lto_codegen_set_should_embed_uselists is introduced in r235943 but not added to lto.exports. Add to export list to expose the API. Reviewers: dexonsmith Subscribers: rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D10658 llvm-svn: 240442
* add missing dependency on Target lib for toolsSanjay Patel2015-06-031-0/+1
| | | | | | | This was exposed by r238842 (which was reverted by r238900) when doing a CMake build with -DBUILD_SHARED_LIBS=ON. llvm-svn: 238953
* Make the C++ LTO API easier to use from C++ clients.Peter Collingbourne2015-06-011-10/+33
| | | | | | | | | | | Start using C++ types such as StringRef and MemoryBuffer in the C++ LTO API. In doing so, clarify the ownership of the native object file: the caller now owns it, not the LTOCodeGenerator. The C libLTO library has been modified to use a derived class of LTOCodeGenerator that owns the object file. Differential Revision: http://reviews.llvm.org/D10114 llvm-svn: 238776
* LTO: Add API to choose whether to embed uselistsDuncan P. N. Exon Smith2015-04-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | Reverse libLTO's default behaviour for preserving use-list order in bitcode, and add API for controlling it. The default setting is now `false` (don't preserve them), which is consistent with `clang`'s default behaviour. Users of libLTO should call `lto_codegen_should_embed_uselists(CG,true)` prior to calling `lto_codegen_write_merged_modules()` whenever the output file isn't part of the production workflow in order to reproduce results with subsequent calls to `llc`. (I haven't added tests since `llvm-lto` (the test tool for LTO) doesn't support bitcode output, and even if it did: there isn't actually a good way to test whether a tool has passed the flag. If the order is already "natural" (if the order will already round-trip) then no use-list directives are emitted at all. At some point I'll circle back to add tests to `llvm-as` (etc.) that they actually respect the flag, at which point I can somehow add a test here as well.) llvm-svn: 235943
* [LTO API] add lto_codegen_set_should_internalize.Manman Ren2015-04-172-0/+6
| | | | | | | | | | | When debugging LTO issues with ld64, we use -save-temps to save the merged optimized bitcode file, then invoke ld64 again on the single bitcode file. The saved bitcode file is already internalized, so we can call lto_codegen_set_should_internalize and skip running internalization again. rdar://20227235 llvm-svn: 235211
* Fix build failure.Peter Collingbourne2015-03-191-6/+6
| | | | llvm-svn: 232771
* libLTO, llvm-lto, gold: Introduce flag for controlling optimization level.Peter Collingbourne2015-03-191-27/+23
| | | | | | | | | | This change also introduces a link-time optimization level of 1. This optimization level runs only the globaldce pass as well as cleanup passes for passes that run at -O0, specifically simplifycfg which cleans up lowerbitsets. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150316/266951.html llvm-svn: 232769
* Add missing includes. make_unique proliferated everywhere.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230909
* [LTO API] add lto_codegen_set_module to set the destination module.Manman Ren2015-02-242-0/+5
| | | | | | | | | | | | | | | | | | When debugging LTO issues with ld64, we use -save-temps to save the merged optimized bitcode file, then invoke ld64 again on the single bitcode file to speed up debugging code generation passes and ld64 stuff after code generation. llvm linking a single bitcode file via lto_codegen_add_module will generate a different bitcode file from the single input. With the newly-added lto_codegen_set_module, we can make sure the destination module is the same as the input. lto_codegen_set_module will transfer the ownship of the module to code generator. rdar://19024554 llvm-svn: 230290
* Fix duplicated symbol error.Rafael Espindola2015-02-031-0/+2
| | | | llvm-svn: 228012
* [LTO API] split lto_codegen_compile to lto_codegen_optimize andManman Ren2015-02-032-0/+23
| | | | | | | | | | | | | | | | | | | lto_codegen_compile_optimized. Also add lto_api_version. Before this commit, we can only dump the optimized bitcode after running lto_codegen_compile, but it includes some impacts of running codegen passes, one example is StackProtector pass. We will get assertion failure when running llc on the optimized bitcode, because StackProtector is effectively run twice. After splitting lto_codegen_compile, the linker can choose to dump the bitcode before running lto_codegen_compile_optimized. lto_api_version is added so ld64 can check for runtime-availability of the new API. rdar://19565500 llvm-svn: 228000
* [lto] Disable dialog boxes on crash on Windows.Michael J. Spencer2015-01-291-0/+7
| | | | | | This has to be done in the DLL because the state doesn't cross DLL boundaries. llvm-svn: 227471
* Unbreak cmake build with shared libraries enabled.Matthias Braun2014-12-201-0/+1
| | | | llvm-svn: 224661
* LTO: Export local context symbolsDuncan P. N. Exon Smith2014-12-192-2/+16
| | | | | | | | Export symbols in libLTO.dylib for the local context-related functions added in r221733 (`LTO_API_VERSION=11`)... and add the missing definition for `lto_codegen_create_in_local_context()`. llvm-svn: 224567
* libLTO: Allow linker to choose context of modules and codegenDuncan P. N. Exon Smith2014-11-111-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add API for specifying which `LLVMContext` each `lto_module_t` and `lto_code_gen_t` is in. In particular, this enables the following flow: for (auto &File : Files) { lto_module_t M = lto_module_create_in_local_context(File...); querySymbols(M); lto_module_dispose(M); } lto_code_gen_t CG = lto_codegen_create_in_local_context(); for (auto &File : FilesToLink) { lto_module_t M = lto_module_create_in_codegen_context(File..., CG); lto_codegen_add_module(CG, M); lto_module_dispose(M); } lto_codegen_compile(CG); lto_codegen_write_merged_modules(CG, ...); lto_codegen_dispose(CG); This flow has a few benefits. - Only one module (two if you count the combined module in the code generator) is in memory at a time. - Metadata (and constants) from files that are parsed to query symbols but not linked into the code generator don't pollute the global context. - The first for loop can be parallelized, since each module is in its own context. - When the code generator is disposed, the memory from LTO gets freed. rdar://problem/18767512 llvm-svn: 221733
* Add an option to the LTO code generator to disable vectorization during LTOArnold Schwaighofer2014-10-261-3/+9
| | | | | | | | | | | | | | | | | | | | We used to always vectorize (slp and loop vectorize) in the LTO pass pipeline. r220345 changed it so that we used the PassManager's fields 'LoopVectorize' and 'SLPVectorize' out of the desire to be able to disable vectorization using the cl::opt flags 'vectorize-loops'/'slp-vectorize' which the before mentioned fields default to. Unfortunately, this turns off vectorization because those fields default to false. This commit adds flags to the LTO library to disable lto vectorization which reconciles the desire to optionally disable vectorization during LTO and the desired behavior of defaulting to enabled vectorization. We really want tools to set PassManager flags directly to enable/disable vectorization and not go the route via cl::opt flags *in* PassManagerBuilder.cpp. llvm-svn: 220652
* Update the error handling of lib/Linker.Rafael Espindola2014-10-251-1/+1
| | | | | | Instead of passing a std::string&, use the new diagnostic infrastructure. llvm-svn: 220608
* Remove definition of LLVM_VERSION_INFO; this macro is not used by any of theRichard Smith2014-09-262-6/+0
| | | | | | | | | files in this directory. If it should be defined anywhere, it should be defined when building lib/LTO/LTOCodeGenerator.cpp, but we've not had it defined there for quite some time, so that doesn't really seem to be very important. (It also would slow down the modules build by creating extra module variants.) llvm-svn: 218544
* Remove lto_codegen_set_attr.Rafael Espindola2014-08-011-4/+0
| | | | | | It was never exported, so no functionality change. llvm-svn: 214519
* [CMake] tools/lto: Prune redundant libdep(s).NAKAMURA Takumi2014-07-241-1/+0
| | | | llvm-svn: 213855
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-061-3/+3
| | | | llvm-svn: 212405
* Change LTOModule`s getTargetTriple and setTargetTriple to use c++ types.Rafael Espindola2014-07-041-1/+1
| | | | llvm-svn: 212343
* Sink undesirable LTO functions into the old C APIAlp Toker2014-07-041-2/+9
| | | | | | | | | We want to encourage users of the C++ LTO API to reuse memory buffers instead of repeatedly opening and reading the same file contents. This reverts commit r212305 and implements a tidier scheme. llvm-svn: 212308
* LTO: rename the various makeLTOModule overloads.Peter Collingbourne2014-07-031-6/+6
| | | | | | | | | This rename makes it easier to identify the specific overload being called in each particular case and makes future refactorings easier. Differential Revision: http://reviews.llvm.org/D4370 llvm-svn: 212302
* Don't force the build of toos/lto as a static lib.Rafael Espindola2014-06-271-5/+1
| | | | | | | | Any uses of tools/lto as a static lib should probably move to lib/LTO. This was also never implemented in the configure build, so this reduces the differences among the two. llvm-svn: 211852
* Remove unused includes following r211294Alp Toker2014-06-191-2/+0
| | | | llvm-svn: 211297
* Use the c++ APIs.Rafael Espindola2014-06-191-6/+7
| | | | | | No functionality change. llvm-svn: 211294
* Fix gcc -pedantic warning in lto.cpp.Patrik Hagglund2014-05-051-2/+2
| | | | llvm-svn: 207959
* Move LTOModule and LTOCodeGenerator to the llvm namespace.Rafael Espindola2014-05-031-39/+41
| | | | llvm-svn: 207911
* Style update: don't duplicate comments, they were getting out of sync.Rafael Espindola2014-05-031-73/+0
| | | | llvm-svn: 207909
* Add an -mattr option to the gold plugin to support subtarget features in LTOTom Roeder2014-04-251-0/+22
| | | | | | | | | | This adds support for an -mattr option to the gold plugin and to llvm-lto. This allows the caller to specify details of the subtarget architecture, like +aes, or +ssse3 on x86. Note that this requires a change to the include/llvm-c/lto.h interface: it adds a function lto_codegen_set_attr and it increments the version of the interface. llvm-svn: 207279
* Revert "Reapply "LTO: add API to set strategy for -internalize""Duncan P. N. Exon Smith2014-04-021-7/+0
| | | | | | | | | | | This reverts commit r199244. Conflicts: include/llvm-c/lto.h include/llvm/LTO/LTOCodeGenerator.h lib/LTO/LTOCodeGenerator.cpp llvm-svn: 205471
* Centralize the handling of install_name and rpath.Rafael Espindola2014-02-281-8/+0
| | | | | | | | | | | This centralizes the Makefile handling of -install_name and -rpath. It also moves the cmake build to using @rpath. The reason being that libclang needs it, and it works for everything else. A followup patch will move clang to using this and then there will be a single point to edit to support other systems. llvm-svn: 202499
* [CMake] llvm-c/lto.h should be installed if libLTO.a is built.NAKAMURA Takumi2014-02-211-4/+2
| | | | llvm-svn: 201859
* [CMake] libLTO: Use (SHARED|STATIC) to build both shared LTO and LTO_static.NAKAMURA Takumi2014-02-211-15/+3
| | | | llvm-svn: 201856
* Refactor TargetOptions initialization into a single place.Eli Bendersky2014-02-191-34/+6
| | | | | | | | | | | | The same code (~20 lines) for initializing a TargetOptions object from CodeGen cmdline flags is duplicated 4 times in 4 different tools. This patch moves it into a utility function. Since the CodeGen/CommandFlags.h file defines cl::opt flags in a header, it's a bit of a touchy situation because we should only link them into tools. So this patch puts the init function in the header. llvm-svn: 201699
* LTO API: add lto_module_create_from_memory_with_path.Manman Ren2014-02-102-0/+12
| | | | | | | | | | | | | This function adds an extra path argument to lto_module_create_from_memory. The path argument will be passed to makeBuffer to make sure the MemoryBuffer has a name and the created module has a module identifier. This is mainly for emitting warning messages from the linker. When we emit warning message on a module, we can use the module identifier. rdar://15985737 llvm-svn: 201114
* Revert r200560, "LTO itself hasn't depended on MCDisassembler any more."NAKAMURA Takumi2014-01-312-1/+2
| | | | | | Oh sorry, I missed LTO.exports, ... I checked just only *.cpp(s). llvm-svn: 200562
* LTO itself hasn't depended on MCDisassembler any more.NAKAMURA Takumi2014-01-312-3/+1
| | | | llvm-svn: 200560
OpenPOWER on IntegriCloud