summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* LTO: expose LTO_SYMBOL_COMDAT flag, which indicates that the definition is ↵Peter Collingbourne2015-06-111-0/+3
| | | | | | | | | | | | part of a comdat group. Reviewers: rafael Subscribers: llvm-commits, ruiu Differential Revision: http://reviews.llvm.org/D10330 llvm-svn: 239559
* Make the C++ LTO API easier to use from C++ clients.Peter Collingbourne2015-06-011-14/+7
| | | | | | | | | | | 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-2/+1
| | | | | | | | | | | | | | | | | | | | | | 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: Simplify code generator initializationDuncan P. N. Exon Smith2015-04-271-15/+2
| | | | | | | Simplify `LTOCodeGenerator` initialization by initializing simple fields at their definition. llvm-svn: 235939
* [LTO API] add lto_codegen_set_should_internalize.Manman Ren2015-04-171-1/+2
| | | | | | | | | | | 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
* uselistorder: Remove the global bitsDuncan P. N. Exon Smith2015-04-151-6/+1
| | | | | | | | | | | | | Remove all the global bits to do with preserving use-list order by moving the `cl::opt`s to the individual tools that want them. There's a minor functionality change to `libLTO`, in that you can't send in `-preserve-bc-uselistorder=false`, but making that bit settable (if it's worth doing) should be through explicit LTO API. As a drive-by fix, I removed some includes of `UseListOrder.h` that were made unnecessary by recent commits. llvm-svn: 234973
* uselistorder: Pull the bit through WriteToBitcodFile()Duncan P. N. Exon Smith2015-04-151-1/+2
| | | | | | | | | | | Change the callers of `WriteToBitcodeFile()` to pass `true` or `shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers that want to send `false` alone. I'll keep pushing the bit higher until hopefully I can delete the global `cl::opt` entirely. llvm-svn: 234957
* Use raw_pwrite_stream in the object writer/streamer.Rafael Espindola2015-04-141-1/+2
| | | | | | The ELF object writer will take advantage of that in the next commit. llvm-svn: 234950
* IR: Set -preserve-bc-uselistorder=false by defaultDuncan P. N. Exon Smith2015-04-141-0/+5
| | | | | | | But keep it on by default in `llvm-as`, `opt`, `bugpoint`, `llvm-link`, `llvm-extract`, and `LTOCodeGenerator`. Part of PR5680. llvm-svn: 234921
* Simplify use of formatted_raw_ostream.Rafael Espindola2015-04-091-4/+1
| | | | | | | | | | | | | | | formatted_raw_ostream is a wrapper over another stream to add column and line number tracking. It is used only for asm printing. This patch moves the its creation down to where we know we are printing assembly. This has the following advantages: * Simpler lifetime management: std::unique_ptr * We don't compute column and line number of object files :-) llvm-svn: 234535
* This reverts commit r234460 and r234461.Rafael Espindola2015-04-091-1/+4
| | | | | | | | | Revert "Add classof implementations to the raw_ostream classes." Revert "Use the cast machinery to remove dummy uses of formatted_raw_ostream." The underlying issue can be fixed without classof. llvm-svn: 234495
* Use the cast machinery to remove dummy uses of formatted_raw_ostream.Rafael Espindola2015-04-091-4/+1
| | | | | | | If we know we are producing an object, we don't need to wrap the stream in a formatted_raw_ostream anymore. llvm-svn: 234461
* [LTO] do not run internalize pass from compileOptimized.Manman Ren2015-04-081-3/+0
| | | | | | | | | The input to compileOptimized is already optimized and internalized, so remove internalize pass from compileOptimized. rdar://20227235 llvm-svn: 234446
* Remove more superfluous .str() and replace std::string concatenation with Twine.Yaron Keren2015-03-301-1/+1
| | | | | | Following r233392, http://llvm.org/viewvc/llvm-project?rev=233392&view=rev. llvm-svn: 233555
* Verifier: Remove the separate -verify-di passDuncan P. N. Exon Smith2015-03-191-1/+0
| | | | | | | | | | | | | | Remove `DebugInfoVerifierLegacyPass` and the `-verify-di` pass. Instead, call into the `DebugInfoVerifier` from inside `VerifierLegacyPass::finalizeModule()`. This better matches the logic in `verifyModule()` (used by the new PassManager), avoids requiring two separate passes to verify the IR, and makes the API for "add a pass to verify the IR" simple. Note: the `-verify-debug-info` flag still works (for now, at least; eventually it might make sense to just remove it). llvm-svn: 232772
* libLTO, llvm-lto, gold: Introduce flag for controlling optimization level.Peter Collingbourne2015-03-191-10/+22
| | | | | | | | | | 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 a parameter for getLazyBitcodeModule to lazily load Metadata.Manman Ren2015-03-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | We only defer loading metadata inside ParseModule when ShouldLazyLoadMetadata is true and we have not loaded any Metadata block yet. This commit implements all-or-nothing loading of Metadata. If there is a request to load any metadata block, we will load all deferred metadata blocks. We make sure the deferred metadata blocks are loaded before we materialize any function or a module. The default value of the added parameter ShouldLazyLoadMetadata for getLazyBitcodeModule is false, so the default behavior stays the same. We only set the parameter to true when creating LTOModule in local contexts. These can only really be used for parsing symbols, so it's unnecessary to ever load the metadata blocks. If we are going to enable lazy-loading of Metadata for other usages of getLazyBitcodeModule, where deferred metadata blocks need to be loaded, we can expose BitcodeReader::materializeMetadata to Module, similar to Module::materialize. rdar://19804575 llvm-svn: 232198
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-042-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* [LTO API] fix memory leakage introduced at r230290.Manman Ren2015-02-251-4/+15
| | | | | | | | r230290 released the LLVM module but not the LTOModule. rdar://19024554 llvm-svn: 230544
* [LTO API] add lto_codegen_set_module to set the destination module.Manman Ren2015-02-241-0/+16
| | | | | | | | | | | | | | | | | | 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
* [PM] Remove the old 'PassManager.h' header file at the top level ofChandler Carruth2015-02-131-4/+4
| | | | | | | | | | | | | | | | | | | | LLVM's include tree and the use of using declarations to hide the 'legacy' namespace for the old pass manager. This undoes the primary modules-hostile change I made to keep out-of-tree targets building. I sent an email inquiring about whether this would be reasonable to do at this phase and people seemed fine with it, so making it a reality. This should allow us to start bootstrapping with modules to a certain extent along with making it easier to mix and match headers in general. The updates to any code for users of LLVM are very mechanical. Switch from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h". Qualify the types which now produce compile errors with "legacy::". The most common ones are "PassManager", "PassManagerBase", and "FunctionPassManager". llvm-svn: 229094
* Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.Zachary Turner2015-02-111-0/+3
| | | | | | | | | | This allows IDEs to recognize the entire set of header files for each of the core LLVM projects. Differential Revision: http://reviews.llvm.org/D7526 Reviewed By: Chris Bieneman llvm-svn: 228798
* [LTO API] split lto_codegen_compile to lto_codegen_optimize andManman Ren2015-02-031-26/+53
| | | | | | | | | | | | | | | | | | | 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
* Only access TLOF via the TargetMachine, not TargetLowering.Eric Christopher2015-02-031-4/+2
| | | | llvm-svn: 227949
* [multiversion] Implement the old pass manager's TTI wrapper pass inChandler Carruth2015-02-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | terms of the new pass manager's TargetIRAnalysis. Yep, this is one of the nicer bits of the new pass manager's design. Passes can in many cases operate in a vacuum and so we can just nest things when convenient. This is particularly convenient here as I can now consolidate all of the TargetMachine logic on this analysis. The most important change here is that this pushes the function we need TTI for all the way into the TargetMachine, and re-creates the TTI object for each function rather than re-using it for each function. We're now prepared to teach the targets to produce function-specific TTI objects with specific subtargets cached, etc. One piece of feedback I'd love here is whether its worth renaming any of this stuff. None of the names really seem that awesome to me at this point, but TargetTransformInfoWrapperPass is particularly ... odd. TargetIRAnalysisWrapper might make more sense. I would want to do that rename separately anyways, but let me know what you think. llvm-svn: 227731
* [CMake] LLVMLTO requires Intrinsics.gen since r227685 introduced ↵NAKAMURA Takumi2015-02-011-0/+2
| | | | | | llvm/Analysis/TargetTransformInfo.h. llvm-svn: 227700
* [PM] Switch the TargetMachine interface from accepting a pass managerChandler Carruth2015-01-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | base which it adds a single analysis pass to, to instead return the type erased TargetTransformInfo object constructed for that TargetMachine. This removes all of the pass variants for TTI. There is now a single TTI *pass* in the Analysis layer. All of the Analysis <-> Target communication is through the TTI's type erased interface itself. While the diff is large here, it is nothing more that code motion to make types available in a header file for use in a different source file within each target. I've tried to keep all the doxygen comments and file boilerplate in line with this move, but let me know if I missed anything. With this in place, the next step to making TTI work with the new pass manager is to introduce a really simple new-style analysis that produces a TTI object via a callback into this routine on the target machine. Once we have that, we'll have the building blocks necessary to accept a function argument as well. llvm-svn: 227685
* [PM] Sink the population of the pass manager with target-specificChandler Carruth2015-01-301-1/+4
| | | | | | | | | | | | analyses back into the LTO code generator. The pass manager builder (and the transforms library in general) shouldn't be referencing the target machine at all. This makes the LTO population work like the others -- the data layout and target transform info need to be pre-populated. llvm-svn: 227576
* [LTO] Scan all per-function subtargets when collecting runtime library names.Akira Hatanaka2015-01-301-12/+22
| | | | | | | | | | | | accumulateAndSortLibcalls in LTOCodeGenerator.cpp collects names of runtime library functions which are used to identify user-defined functions that should be protected. Previously, this function would only scan the TargetLowering object belonging to the "main" subtarget for the library function names. This commit changes it to scan all per-function subtargets. Differential Revision: http://reviews.llvm.org/D7275 llvm-svn: 227533
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-262-3/+3
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
OpenPOWER on IntegriCloud