summaryrefslogtreecommitdiffstats
path: root/llvm/lib/LTO
Commit message (Collapse)AuthorAgeFilesLines
...
* Update libdeps since TLI was moved from Target to Analysis in r226078.NAKAMURA Takumi2015-01-151-1/+1
| | | | llvm-svn: 226126
* Reorder.NAKAMURA Takumi2015-01-151-1/+1
| | | | llvm-svn: 226125
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Use the DiagnosticHandler to print diagnostics when reading bitcode.Rafael Espindola2015-01-101-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
* LTO: Lazy-load LTOModule in local contextsDuncan P. N. Exon Smith2014-12-171-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | Start lazy-loading `LTOModule`s that own their contexts. These can only really be used for parsing symbols, so its unnecessary to ever materialize their functions. I looked into using `IRObjectFile::create()` and optionally calling `materializAllPermanently()` afterwards, but this turned out to be awkward. - The default target triple and data layout logic needs to happen *before* the call to `IRObjectFile::IRObjectFile()`, but after `Module` was created. - I tried passing a lambda in to do the module initialization, but this seemed to require threading the error message from `TargetRegistry::lookupTarget()` through `std::error_code`. - I also looked at setting `errMsg` directly from within the lambda, but this didn't look any better. (I guess there's a reason we weren't already using that function.) llvm-svn: 224466
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* Remove StringMap::GetOrCreateValue in favor of StringMap::insertDavid Blaikie2014-11-191-50/+38
| | | | | | | | | | | | | | Having two ways to do this doesn't seem terribly helpful and consistently using the insert version (which we already has) seems like it'll make the code easier to understand to anyone working with standard data structures. (I also updated many references to the Entry's key and value to use first() and second instead of getKey{Data,Length,} and get/setValue - for similar consistency) Also removes the GetOrCreateValue functions so there's less surface area to StringMap to fix/improve/change/accommodate move semantics, etc. llvm-svn: 222319
* libLTO: Assert if LTOCodeGenerator and LTOModule are from different contextsDuncan P. N. Exon Smith2014-11-111-0/+3
| | | | llvm-svn: 221730
* libLTO: Allow LTOModule to own a contextDuncan P. N. Exon Smith2014-11-111-8/+43
| | | | llvm-svn: 221728
* libLTO: Allow LTOCodeGenerator to own a contextDuncan P. N. Exon Smith2014-11-111-4/+18
| | | | llvm-svn: 221726
* 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-2/+2
| | | | | | Instead of passing a std::string&, use the new diagnostic infrastructure. llvm-svn: 220608
* LTO: Document the Boolean argument from r218784Duncan P. N. Exon Smith2014-10-021-1/+2
| | | | llvm-svn: 218907
* LTO: Ignore disabled diagnostic remarksDuncan P. N. Exon Smith2014-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | r206400 and r209442 added remarks that are disabled by default. However, if a diagnostic handler is registered, the remarks are sent unfiltered to the handler. This is the right behaviour for clang, since it has its own filters. However, the diagnostic handler exposed in the LTO API receives only the severity and message. It doesn't have the information to filter by pass name. For LTO, disabled remarks should be filtered by the producer. I've changed `LLVMContext::setDiagnosticHandler()` to take a `bool` argument indicating whether to respect the built-in filters. This defaults to `false`, so other consumers don't have a behaviour change, but `LTOCodeGenerator::setDiagnosticHandler()` sets it to `true`. To make this behaviour testable, I added a `-use-diagnostic-handler` command-line option to `llvm-lto`. This fixes PR21108. llvm-svn: 218784
* LTO: introduce object file-based on-disk module format.Peter Collingbourne2014-09-181-13/+30
| | | | | | | | | | | | | | | | | | This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
* Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola2014-09-101-1/+1
| | | | | | | | | | | | | With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
* unique_ptrify LTOCodeGenerator::NativeObjectFileDavid Blaikie2014-09-021-7/+2
| | | | llvm-svn: 216927
* Return a std::unique_ptr when creating a new MemoryBuffer.Rafael Espindola2014-08-271-2/+1
| | | | llvm-svn: 216583
* Fix some cases were ArrayRefs were being passed by reference. Also remove ↵Craig Topper2014-08-271-1/+1
| | | | | | 'const' from some other ArrayRef uses since its implicitly const already. llvm-svn: 216524
* Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola2014-08-261-9/+3
| | | | | | | | | | | | | The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
* Simplify LTOModule::makeLTOModule a bit. NFC.Rafael Espindola2014-08-261-3/+1
| | | | | | | Just call parseBitcodeFile instead of getLazyBitcodeModule followed by materializeAllPermanently. llvm-svn: 216461
* Modernize raw_fd_ostream's constructor a bit.Rafael Espindola2014-08-251-3/+3
| | | | | | | | | | Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error. A create static method would be even better, but this patch is already a bit too big. llvm-svn: 216393
* Move some logic to populateLTOPassManager.Rafael Espindola2014-08-211-22/+11
| | | | | | | This will avoid code duplication in the next commit which calls it directly from the gold plugin. llvm-svn: 216211
* Respect LibraryInfo in populateLTOPassManager and use it. NFC.Rafael Espindola2014-08-211-3/+2
| | | | llvm-svn: 216203
* Handle inlining in populateLTOPassManager like in populateModulePassManager.Rafael Espindola2014-08-211-1/+3
| | | | | | No functionality change. llvm-svn: 216178
* Move DisableGVNLoadPRE from populateLTOPassManager to PassManagerBuilder.Rafael Espindola2014-08-211-3/+5
| | | | llvm-svn: 216174
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-2/+2
| | | | | | needing to mention the size. llvm-svn: 216158
* Silencing a -Wcast-qual warning. NFC.Aaron Ballman2014-08-201-1/+1
| | | | llvm-svn: 216068
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-2/+2
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-2/+2
| | | | | | needing to mention the size. llvm-svn: 215868
* Return a std::uinque_ptr. Every caller was already using one.Rafael Espindola2014-08-171-3/+4
| | | | llvm-svn: 215858
* Don't internalize all but main by default.Rafael Espindola2014-08-051-4/+2
| | | | | | | | | | | | | | | This is mostly a cleanup, but it changes a fairly old behavior. Every "real" LTO user was already disabling the silly internalize pass and creating the internalize pass itself. The difference with this patch is for "opt -std-link-opts" and the C api. Now to get a usable behavior out of opt one doesn't need the funny looking command line: opt -internalize -disable-internalize -internalize-public-api-list=foo,bar -std-link-opts llvm-svn: 214919
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-042-6/+11
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Attempt at fixing the windows dll build.Rafael Espindola2014-07-301-1/+1
| | | | | | | It looks like only direct (i.e., explicitly listed) dependencies are scanned. llvm-svn: 214361
* Refactor duplicated code.Rafael Espindola2014-07-301-23/+2
| | | | llvm-svn: 214328
* Add the missing hasLinkOnceODRLinkage predicate.Rafael Espindola2014-07-301-3/+1
| | | | llvm-svn: 214312
* AArch64: remove arm64 triple enumerator.Tim Northover2014-07-232-4/+2
| | | | | | | | | | | | Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
* MergedLoadStoreMotion passGerolf Hoflehner2014-07-181-0/+1
| | | | | | | | | | | Merges equivalent loads on both sides of a hammock/diamond and hoists into into the header. Merges equivalent stores on both sides of a hammock/diamond and sinks it to the footer. Can enable if conversion and tolerate better load misses and store operand latencies. llvm-svn: 213396
* Prune Redundant libdeps in CMake's target_link_libraries and LLVMBuild.txt.NAKAMURA Takumi2014-07-151-1/+1
| | | | | | I checked this with Release+Asserts on x86_64-mingw32. Please restore partially if this were overkill. llvm-svn: 213064
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-062-13/+15
| | | | llvm-svn: 212405
* Revert "Convert a few std::strings to StringRef."Rafael Espindola2014-07-041-2/+2
| | | | | | | | | This reverts commit r212342. We can get a StringRef into the current Record, but not one in the bitcode itself since the string is compressed in it. llvm-svn: 212356
* Ignore llvm specific symbols in the LTOModule.Rafael Espindola2014-07-041-0/+3
| | | | | | | | | | These are the llvm.* globals and functions. I don't think it is possible to test this directly since llvm-lto is not a full linker and will not report duplicated symbols, but this fixes bootstrap with gold and lto enabled. llvm-svn: 212354
* Implement LTOModule on top of IRObjectFile.Rafael Espindola2014-07-042-127/+76
| | | | | | | | | | | | | IRObjectFile provides all the logic for producing mangled names and getting symbols from inline assembly. LTOModule then adds logic for linking specific tasks, like constructing llvm.compiler_user or extracting linker options from the bitcode. The rule of the thumb is that IRObjectFile has the functionality that is needed by both LTO and llvm-ar. llvm-svn: 212349
* Avoid mangling names twice. No functionality change.Rafael Espindola2014-07-041-18/+24
| | | | llvm-svn: 212348
* Convert a few std::strings to StringRef.Rafael Espindola2014-07-041-2/+2
| | | | llvm-svn: 212342
* Fix prefix comparison from r212308Alp Toker2014-07-041-1/+2
| | | | llvm-svn: 212310
* Sink undesirable LTO functions into the old C APIAlp Toker2014-07-041-24/+3
| | | | | | | | | 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
* Modify LTOModule::isTargetMatch to take a StringRef instead of a MemoryBuffer.Peter Collingbourne2014-07-031-8/+8
| | | | llvm-svn: 212305
* LTO: rename the various makeLTOModule overloads.Peter Collingbourne2014-07-031-16/+13
| | | | | | | | | 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
OpenPOWER on IntegriCloud