summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Switch lto codegen to using diagnostic handlers.Yunzhong Gao2015-11-171-28/+44
| | | | | | | | | | | 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-8/+2
| | | | | | | | | | | | | | 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
* Add a method to the BitcodeReader to parse only the identification blockMehdi Amini2015-11-091-0/+9
| | | | | | | | | | | Summary: Mimic parseTriple(); and exposes it to LTOModule.cpp Reviewers: dexonsmith, rafael Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 252442
* Reapply "LTO: Disable extra verify runs in release builds"Duncan P. N. Exon Smith2015-09-151-8/+13
| | | | | | | 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-13/+8
| | | | | | | 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-8/+13
| | | | | | | | | | | | | | | | | | | | | | 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
* [PM] Port SROA to the new pass manager.Chandler Carruth2015-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some ways this is a very boring port to the new pass manager as there are no interesting analyses or dependencies or other oddities. However, this does introduce the first good example of a transformation pass with non-trivial state porting to the new pass manager. I've tried to carve out patterns here to replicate elsewhere, and would appreciate comments on whether folks like these patterns: - A common need in the new pass manager is to effectively lift the pass class and some of its state into a public header file. Prior to this, LLVM used anonymous namespaces to provide "module private" types and utilities, but that doesn't scale to cases where a public header file is needed and the new pass manager will exacerbate that. The pattern I've adopted here is to use the namespace-cased-name of the core pass (what would be a module if we had them) as a module-private namespace. Then utility and other code can be declared and defined in this namespace. At some point in the future, we could even have (conditionally compiled) code that used modules features when available to do the same basic thing. - I've split the actual pass run method in two in order to expose a private method usable by the old pass manager to wrap the new class with a minimum of duplicated code. I actually looked at a bunch of ways to automate or generate these, but they are all quite terrible IMO. The fundamental need is to extract the set of analyses which need to cross this interface boundary, and that will end up being too unpredictable to effectively encapsulate IMO. This is also a relatively small amount of boiler plate that will live a relatively short time, so I'm not too worried about the fact that it is boiler plate. The rest of the patch is totally boring but results in a massive diff (sorry). It just moves code around and removes or adds qualifiers to reflect the new name and nesting structure. Differential Revision: http://reviews.llvm.org/D12773 llvm-svn: 247501
* Add a non-exiting diagnostic handler for LTO.Yunzhong Gao2015-09-111-2/+8
| | | | | | | This is in order to give LTO clients a chance to do some clean-up before terminating the process. llvm-svn: 247461
* [PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatibleChandler Carruth2015-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
* Fix typo.Yaron Keren2015-09-011-1/+1
| | | | llvm-svn: 246538
* LTO: Cleanup parameter names and header docs, NFCDuncan P. N. Exon Smith2015-08-311-53/+48
| | | | | | | | Follow LLVM style for the parameter names (`CamelCase` not `camelCase`), and surface the header docs in doxygen. No functionality change intended. llvm-svn: 246509
* CodeGen: Introduce splitCodeGen and teach LTOCodeGenerator to use it.Peter Collingbourne2015-08-271-13/+15
| | | | | | | | | | | | | | | llvm::splitCodeGen is a function that implements the core of parallel LTO code generation. It uses llvm::SplitModule to split the module into linkable partitions and spawning one code generation thread per partition. The function produces multiple object files which can be linked in the usual way. This has been threaded through to LTOCodeGenerator (and llvm-lto for testing purposes). Separate patches will add parallel LTO support to the gold plugin and lld. Differential Revision: http://reviews.llvm.org/D12260 llvm-svn: 246236
* LTO: Simplify merged module ownership.Peter Collingbourne2015-08-241-28/+12
| | | | | | | | | | | 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: Rename mergedModule variables to MergedModule to prepare for ownership ↵Peter Collingbourne2015-08-241-20/+17
| | | | | | | | change. Also convert a few loops to range-for loops and correct a comment. llvm-svn: 245874
* LTO: Maintain target triple, FeatureStr and CGOptLevel in the module or ↵Peter Collingbourne2015-08-221-18/+22
| | | | | | | | LTOCodeGenerator. This makes it easier to create new TargetMachines on demand. llvm-svn: 245781
* LTO: Change signature of LTOCodeGenerator::setCodePICModel() to take a ↵Peter Collingbourne2015-08-211-30/+0
| | | | | | | | | 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: Simplify ownership of LTOCodeGenerator::TargetMach.Peter Collingbourne2015-08-211-6/+3
| | | | llvm-svn: 245671
* LTO: Simplify ownership of LTOCodeGenerator::CodegenOptions.Peter Collingbourne2015-08-211-15/+9
| | | | llvm-svn: 245670
* [PM/AA] Remove the last relics of the separate IPA library from LLVM,Chandler Carruth2015-08-181-1/+0
| | | | | | | | | | | | | | | | | | | | | folding the code into the main Analysis library. There already wasn't much of a distinction between Analysis and IPA. A number of the passes in Analysis are actually IPA passes, and there doesn't seem to be any advantage to separating them. Moreover, it makes it hard to have interactions between analyses that are both local and interprocedural. In trying to make the Alias Analysis infrastructure work with the new pass manager, it becomes particularly awkward to navigate this split. I've tried to find all the places where we referenced this, but I may have missed some. I have also adjusted the C API to continue to be equivalently functional after this change. Differential Revision: http://reviews.llvm.org/D12075 llvm-svn: 245318
* Remove access to the DataLayout in the TargetMachineMehdi Amini2015-07-242-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243114
* Revert "Remove access to the DataLayout in the TargetMachine"Mehdi Amini2015-07-242-2/+2
| | | | | | | | | | This reverts commit 0f720d984f419c747709462f7476dff962c0bc41. It breaks clang too badly, I need to prepare a proper patch for clang first. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243089
* Remove access to the DataLayout in the TargetMachineMehdi Amini2015-07-242-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243083
* LTO: expose LTO_SYMBOL_ALIAS, which indicates that the symbol is an alias.Peter Collingbourne2015-07-041-0/+3
| | | | | | | | This is needed for COFF linkers to distinguish between weak external aliases and regular symbols with LLVM weak linkage, which are represented as strong symbols in COFF. llvm-svn: 241389
* Teach LTOModule to emit linker flags for dllexported symbols, plus interface ↵Peter Collingbourne2015-06-291-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify the Mangler interface now that DataLayout is mandatory.Rafael Espindola2015-06-231-1/+1
| | | | | | | We only need to pass in a DataLayout when mangling a raw string, not when constructing the mangler. llvm-svn: 240405
* Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.Rafael Espindola2015-06-161-11/+12
| | | | llvm-svn: 239858
* Wrap some long lines in LLVMBuild files. NFCDouglas Katzman2015-06-121-1/+16
| | | | | | | As suggested by jroelofs in a prior review (D9752), it makes sense to generally prefer multi-line format. llvm-svn: 239632
OpenPOWER on IntegriCloud