summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* Add SVN version to libLLVMLTOMehdi Amini2016-04-161-0/+50
| | | | | | | | | | | | | | | | | | | | Summary: For Incremental LTO, we need to make sure that an old cache entry is not used when incrementally re-linking with a new libLTO. Adding a global LLVM_REVISION in llvm-config.h would for to rebuild/relink the world for every "git pull"/"svn update". So instead only libLTO is made dependent on the VCS and will be rebuilt (and the dependent binaries relinked, i.e. as of today: libLTO.dylib and llvm-lto). Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18987 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266523
* ThinLTO: Move the ODR resolution to be based purely on the summary.Mehdi Amini2016-04-161-47/+91
| | | | | | | | | This is a requirement for the cache handling in D18494 Differential Revision: http://reviews.llvm.org/D18908 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266519
* ThinLTO: linkonce compile-time optimization, do not bother when there is ↵Mehdi Amini2016-04-141-0/+4
| | | | | | | only one input file From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266281
* Simplify LTOInternalize into UpdateLLVMCompilerUsedMehdi Amini2016-04-135-95/+91
| | | | | | | | | It is now only doing the update to the llvm.compiler_used global. The client has to call separately the internalization stage. Hopefully the code is simpler to understand this way. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266174
* Minor cleanup in Internalize, hide helper class using anonymous namespace (NFC)Mehdi Amini2016-04-132-0/+0
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266173
* LTOInternalize: Use a StringSet instead of a sorted vector and a binary ↵Mehdi Amini2016-04-131-9/+4
| | | | | | | search query for each function From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266172
* Move "ExternalSymbols" out of LTOInternalize (NFC)Mehdi Amini2016-04-133-18/+22
| | | | | | | This is not really related to internalization per se. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266170
* Refactor the InternalizePass into a helper class, and expose it through a ↵Mehdi Amini2016-04-131-6/+2
| | | | | | | | | | public free function (NFC) There is really no reason to require to instanciate a pass manager to internalize. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266167
* Refactor Internalization pass to use as a callback instead of a StringSet (NFC)Mehdi Amini2016-04-133-35/+41
| | | | | | | | | | | | This will save a bunch of copies / initialization of intermediate datastructure, and (hopefully) simplify the code. This also abstract the symbol preservation mechanism outside of the Internalization pass into the client code, which is not forced to keep a map of strings for instance (ThinLTO will prefere hashes). From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266163
* LTOInternalize: Fix member type, should be a reference and not a copyMehdi Amini2016-04-121-1/+1
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266153
* Avoid GCC -fpermissive error about llvm::Mangler hidden by member named ManglerStephan Bergmann2016-04-121-1/+1
| | | | llvm-svn: 266049
* Refactor the Internalize stage of libLTO in a separate file (NFC)Mehdi Amini2016-04-124-135/+230
| | | | | | | | | | | | | | | | | This is intended to be shared by the ThinLTOCodeGenerator. Note that there is a change in the way the verifier is run, previously it was ran as a Pass on the merged module during internalization. While now the verifier is called explicitely on the merged module outside of the internalize "pass pipeline". What remains strange in the API is the fact that `DisableVerify` in the API does not disable this initial verifier. Differential Revision: http://reviews.llvm.org/D19000 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266047
* [ThinLTO] Move summary computation from BitcodeWriter to new passTeresa Johnson2016-04-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
* [gold] Save bitcode for module partitions (save-temps + split codegen).Evgeniy Stepanov2016-04-061-4/+3
| | | | llvm-svn: 265583
* Clean up calls to WriteBitcodeToFile (NFC)Teresa Johnson2016-04-041-1/+1
| | | | | | | | | | | Remove a default parameter value being passed unnecessarily, which also reduces the changes required when this parameter is changed in D18763. Document the remaining non-default bool value passed for another parameter. llvm-svn: 265348
* Revert "ThinLTO: add module caching handling."Mehdi Amini2016-04-021-95/+1
| | | | | | | This reverts commit r265214, unintentionally commited. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265216
* ThinLTO: add module caching handling.Mehdi Amini2016-04-021-1/+95
| | | | | | | | | | | Reviewers: tejohnson Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18494 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265214
* Fix -Wpedantic warning about extra semi-colonHans Wennborg2016-04-021-1/+1
| | | | llvm-svn: 265204
* ThinLTO: special handling for LinkOnce functionsMehdi Amini2016-04-011-0/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | These function can be dropped by the compiler if they are no longer referenced in the current module. However there is a change that another module is still referencing them because of the import. Multiple solutions can be used: - Always import LinkOnce when a caller is imported. This ensure that every module with a call to a LinkOnce has the definition and will be able to emit it if it emits the call. - Turn the LinkOnce into Weak, so that it is always emitted. - Turn all LinkOnce into available_externally and come back after all modules are codegen'ed to emit only one copy of the linkonce, when there is still a reference to it. This patch implement the second option, with am optimization that only *one* module will turn the LinkOnce into Weak, while the others will turn it into available_externally, so that there is exactly one copy emitted for the whole compilation. http://reviews.llvm.org/D18346 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265190
* ThinLTO: move ObjCARCContractPass in the CodeGen pipelineMehdi Amini2016-04-011-1/+6
| | | | | | | This is to be coherent with Full LTO. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265118
* Add a libLTO API to stop/restart ThinLTO between optimizations and CodeGenMehdi Amini2016-04-011-2/+35
| | | | | | | | This allows the linker to instruct ThinLTO to perform only the optimization part or only the codegen part of the process. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265113
* ThinLTO: use the callgraph from the combined index to drive the FunctionImporterMehdi Amini2016-03-261-8/+26
| | | | | | | | | | | | | | | | | | Summary: Now that the summary contains the full reference/call graph, we can replace the existing function importer that loads and inspect the IR to iteratively walk the call graph by a traversal based purely on the summary information. Decouple the actual importing decision from any IR manipulation. Reviewers: tejohnson Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18343 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 264503
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-151-16/+16
| | | | | | | | | | | | | | | (Resubmitting after fixing missing file issue) With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263513
* Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"Teresa Johnson2016-03-141-16/+16
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-141-16/+16
| | | | | | | | | | | | | With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes. A companion clang patch will immediately succeed this patch to reflect this renaming. llvm-svn: 263490
* [ThinLTO] Support for reference graph in per-module and combined summary.Teresa Johnson2016-03-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary. The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses. The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId. The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable. Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow. Reviewers: joker.eph, davidxl Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17212 llvm-svn: 263275
* [PM] Port GVN to the new pass manager, wire it up, and teach a couple ofChandler Carruth2016-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | tests to run GVN in both modes. This is mostly the boring refactoring just like SROA and other complex transformation passes. There is some trickiness in that GVN's ValueNumber class requires hand holding to get to compile cleanly. I'm open to suggestions about a better pattern there, but I tried several before settling on this. I was trying to balance my desire to sink as much implementation detail into the source file as possible without introducing overly many layers of abstraction. Much like with SROA, the design of this system is made somewhat more cumbersome by the need to support both pass managers without duplicating the significant state and logic of the pass. The same compromise is struck here. I've also left a FIXME in a doxygen comment as the GVN pass seems to have pretty woeful documentation within it. I'd like to submit this with the FIXME and let those more deeply familiar backfill the information here now that we have a nice place in an interface to put that kind of documentaiton. Differential Revision: http://reviews.llvm.org/D18019 llvm-svn: 263208
* Rename -discard-value-names into -lto-discard-value-names in libLLVMLTOMehdi Amini2016-03-101-2/+2
| | | | | | | | | | This is avoiding a naming conflict with opt and llc. While opt and llc don't link to LTO usually, users that are building a monolithic libLLVM.dylib and linking the tools to it would have a runtime error because of the duplicate cl::opt registration. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263127
* Add a flag to the LLVMContext to disable name for Value other than GlobalValueMehdi Amini2016-03-102-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is intended to be a performance flag, on the same level as clang cc1 option "--disable-free". LLVM will never initialize it by default, it will be up to the client creating the LLVMContext to request this behavior. Clang will do it by default in Release build (just like --disable-free). "opt" and "llc" can opt-in using -disable-named-value command line option. When performing LTO on llvm-tblgen, the initial merging of IR peaks at 92MB without this patch, and 86MB after this patch,setNameImpl() drops from 6.5MB to 0.5MB. The total link time goes from ~29.5s to ~27.8s. Compared to a compile-time flag (like the IRBuilder one), it performs very close. I profiled on SROA and obtain these results: 420ms with IRBuilder that preserve name 372ms with IRBuilder that strip name 375ms with IRBuilder that preserve name, and a runtime flag to strip Reviewers: chandlerc, dexonsmith, bogner Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263086
* libLTO: add a ThinLTOCodeGenerator on the model of LTOCodeGenerator.Mehdi Amini2016-03-094-1/+399
| | | | | | | | | | | | | | | | | This is intended to provide a parallel (threaded) ThinLTO scheme for linker plugin use through the libLTO C API. The intent of this patch is to provide a first implementation as a proof-of-concept and allows linker to start supporting ThinLTO by definiing the libLTO C API. Some part of the libLTO API are left unimplemented yet. Following patches will add support for these. The current implementation can link all clang/llvm binaries. Differential Revision: http://reviews.llvm.org/D17066 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 262977
* Fix some warnings a bit harder/differentDavid Blaikie2016-03-011-1/+1
| | | | | | | This is an alternate fix to 262378 and a fix to a pessimizing-move warning. llvm-svn: 262390
* [LTO] Fix error reporting from lto_module_create_in_local_context()Petr Pavlu2016-03-011-34/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Function lto_module_create_in_local_context() would previously rely on the default LLVMContext being created for it by LTOModule::makeLTOModule(). This context exits the program on error and is not arranged to update sLastStringError in tools/lto/lto.cpp. Function lto_module_create_in_local_context() now creates an LLVMContext by itself, sets it up correctly to its needs and then passes it to LTOModule::createInLocalContext() which takes ownership of the context and keeps it present for the lifetime of the returned LTOModule. Function LTOModule::makeLTOModule() is modified to take a reference to LLVMContext (instead of a pointer) and no longer creates a default context when nullptr is passed to it. Method LTOModule::createInContext() that takes a pointer to LLVMContext is removed because it allows to pass a nullptr to it. Instead LTOModule::createFromBuffer() (that takes a reference to LLVMContext) should be used. Differential Revision: http://reviews.llvm.org/D17715 llvm-svn: 262330
* [PM] Port the PostOrderFunctionAttrs pass to the new pass manager andChandler Carruth2016-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | convert one test to use this. This is a particularly significant milestone because it required a working per-function AA framework which can be queried over each function from within a CGSCC transform pass (and additionally a module analysis to be accessible). This is essentially *the* point of the entire pass manager rewrite. A CGSCC transform is able to query for multiple different function's analysis results. It works. The whole thing appears to actually work and accomplish the original goal. While we were able to hack function attrs and basic-aa to "work" in the old pass manager, this port doesn't use any of that, it directly leverages the new fundamental functionality. For this to work, the CGSCC framework also has to support SCC-based behavior analysis, etc. The only part of the CGSCC pass infrastructure not sorted out at this point are the updates in the face of inlining and running function passes that mutate the call graph. The changes are pretty boring and boiler-plate. Most of the work was factored into more focused preperatory patches. But this is what wires it all together. llvm-svn: 261203
* [LTO] Support StatisticsAdam Nemet2016-02-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: I thought -Xlinker -mllvm -Xlinker -stats worked at some point but maybe it never did. For clang, I believe that stats are printed from cc1_main. This patch also prints them for LTO, specifically right after codegen happens. I only looked at the C API for LTO briefly to see if this is a good place. Probably there are still cases where this wouldn't be printed but it seems to be working for the common case. I also experimented putting this in the LTOCodeGenerator destructor but that didn't trigger for me because ld64 does not destroy the LTOCodeGenerator. Reviewers: dexonsmith, joker.eph Subscribers: rafael, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17302 llvm-svn: 261013
* Move MCTargetAsmParser.h to llvm/MC/MCParser where it belongs.Benjamin Kramer2016-01-271-1/+1
| | | | llvm-svn: 258917
* Remove autoconf supportChris Bieneman2016-01-261-15/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* [LTO] Fix error reporting when a file passed to libLTO is invalid or ↵Petr Pavlu2016-01-201-3/+9
| | | | | | | | | | | | | | | | | | non-existent This addresses PR26060 where function lto_module_create() could return nullptr but lto_get_error_message() returned an empty string. The error() call after LTOModule::createFromFile() in llvm-lto is then removed because any error from this function should go through the diagnostic handler in llvm-lto which will exit the program. The error() call was added because this previously did not happen when the file was non-existent. This is fixed by the patch. (The situation that llvm-lto reports an error when the input file does not exist is tested by llvm/tools/llvm-lto/error.ll). Differential Revision: http://reviews.llvm.org/D16106 llvm-svn: 258298
* [LTO] Restore original linkage of externals prior to splittingTobias Edler von Koch2016-01-181-1/+41
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is a companion patch for http://reviews.llvm.org/D16124. Internalized symbols increase the size of strongly-connected components in SCC-based module splitting and thus reduce the amount of parallelism. This patch records the original linkage of non-local symbols prior to internalization and then restores it just before splitting/CodeGen. This is also useful for cases where the linker requires symbols to remain external, for instance, so they can be placed according to linker script rules. It's currently under its own flag (-restore-globals) but should eventually share a common flag with D16124. Reviewers: joker.eph, pcc Subscribers: slarin, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D16229 llvm-svn: 258100
* [attrs] Split the late-revisit pattern for deducing norecurse inChandler Carruth2016-01-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a top-down manner into a true top-down or RPO pass over the call graph. There are specific patterns of function attributes, notably the norecurse attribute, which are most effectively propagated top-down because all they us caller information. Walk in RPO over the call graph SCCs takes the form of a module pass run immediately after the CGSCC pass managers postorder walk of the SCCs, trying again to deduce norerucrse for each singular SCC in the call graph. This removes a very legacy pass manager specific trick of using a lazy revisit list traversed during finalization of the CGSCC pass. There is no analogous finalization step in the new pass manager, and a lazy revisit list is just trying to produce an RPO iteration of the call graph. We can do that more directly if more expensively. It seems unlikely that this will be the expensive part of any compilation though as we never examine the function bodies here. Even in an LTO run over a very large module, this should be a reasonable fast set of operations over a reasonably small working set -- the function call graph itself. In the future, if this really is a compile time performance issue, we can look at building support for both post order and RPO traversals directly into a pass manager that builds and maintains the PO list of SCCs. Differential Revision: http://reviews.llvm.org/D15785 llvm-svn: 257163
* Rename variables to reflect linker split (NFC)Teresa Johnson2015-12-181-3/+3
| | | | | | | | Renamed variables to be more reflective of whether they are an instance of Linker, IRLinker or ModuleLinker. Also fix a stale comment. llvm-svn: 256011
* Change linkInModule to take a std::unique_ptr.Rafael Espindola2015-12-161-1/+1
| | | | | | | Passing in a std::unique_ptr should help find errors when the module is used after being linked into another module. llvm-svn: 255842
* Use diagnostic handler in the LLVMContextRafael Espindola2015-12-142-8/+4
| | | | | | | | | | | | | | | | This patch converts code that has access to a LLVMContext to not take a diagnostic handler. This has a few advantages * It is easier to use a consistent diagnostic handler in a single program. * Less clutter since we are not passing a handler around. It does make it a bit awkward to implement some C APIs that return a diagnostic string. I will propose new versions of these APIs and deprecate the current ones. llvm-svn: 255571
* MSVC complains about this being ambiguous.Rafael Espindola2015-12-041-2/+2
| | | | llvm-svn: 254782
* Always pass a diagnostic handler to the linker.Rafael Espindola2015-12-041-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Before this patch the diagnostic handler was optional. If it was not passed, the one in the LLVMContext was used. That is probably not a pattern we want to follow. If each area has an optional callback, there is a sea of callbacks and it is hard to follow which one is called. Doing this also found cases where the callback is a nice addition, like testing that no errors or warnings are reported. The other option is to always use the diagnostic handler in the LLVMContext. That has a few problems * To implement the C API we would have to set the diag handler and then set it back to the original value. * Code that creates the context might be far away from code that wants the diagnostics. I do have a patch that implements the second option and will send that as an RFC. llvm-svn: 254777
* Modernize the C++ APIs for creating LTO modules.Rafael Espindola2015-12-041-73/+58
| | | | | | | | | | | | | | | | This is a continuation of r253367. These functions return is owned by the caller, so they return std::unique_ptr now. The call can fail, so the return is wrapped in ErrorOr. They have a context where to report diagnostics, so they don't need to take a string out parameter. With this there are no call to getGlobalContext in lib/LTO. llvm-svn: 254721
* Move a call to getGlobalContext out of lib/LTO.Rafael Espindola2015-12-041-9/+2
| | | | llvm-svn: 254696
* Simplify since this function never fails.Rafael Espindola2015-12-031-10/+2
| | | | llvm-svn: 254667
* Use references now that it is natural to do so.Rafael Espindola2015-12-011-4/+4
| | | | | | | The linker never takes ownership of a module or changes which module it is refering to, making it natural to use references. llvm-svn: 254449
* Delete the setModule method from the Linker.Rafael Espindola2015-12-011-4/+4
| | | | | | | | | | | It was only used from LTO for a debug feature, and LTO can just create another linker. It is pretty odd to have a method to reset the module in the middle of a link. It would make IdentifiedStructTypes inconsistent with the Module for example. llvm-svn: 254434
* [LTO] Add option to emit assembly from LTOCodeGeneratorTobias Edler von Koch2015-11-191-3/+7
| | | | | | | | | | This adds a new API, LTOCodeGenerator::setFileType, to choose the output file format for LTO CodeGen. A corresponding change to use this new API from llvm-lto and a test case is coming in a separate commit. Differential Revision: http://reviews.llvm.org/D14554 llvm-svn: 253622
OpenPOWER on IntegriCloud