summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Linker/LinkModules.cpp
Commit message (Collapse)AuthorAgeFilesLines
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Remember to move a type to the correct set when setting the body.Rafael Espindola2015-03-061-0/+9
| | | | | | | | | We would set the body of a struct type (therefore making it non-opaque) but were forgetting to move it to the non-opaque set. Fixes pr22807. llvm-svn: 231442
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Restore LLVMLinkModules C API until it is properly deprecated.Juergen Ributzka2015-03-021-1/+1
| | | | | | | | | | | Add the enum "LLVMLinkerMode" back for backwards-compatibility and add the linker mode parameter back to the "LLVMLinkModules" function. The paramter is ignored and has no effect. Patch provided by: Filip Pizlo Reviewed by: Rafael and Sean llvm-svn: 230988
* [LTO API] add lto_codegen_set_module to set the destination module.Manman Ren2015-02-241-0/+4
| | | | | | | | | | | | | | | | | | 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
* Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer2015-02-171-8/+4
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
* [LinkModules] Change the way ModuleLinker merges triples.Akira Hatanaka2015-02-131-7/+33
| | | | | | | | | | | | | | | | This commit makes the following changes: - Stop issuing a warning when the triples' string representations do not match exactly if the Triple objects generated from the strings compare equal. - On Apple platforms, choose the triple that has the larger minimum version number. rdar://problem/16743513 Differential Revision: http://reviews.llvm.org/D7591 llvm-svn: 228999
* [llvm link] Destroy ConstantArrays in LLVMContext if they are not used.Manman Ren2015-01-201-1/+3
| | | | | | | | | | | | | | ConstantArrays constructed during linking can cause quadratic memory explosion. An example is the ConstantArrays constructed when linking in GlobalVariables with appending linkage. Releasing all unused constants can cause a 20% LTO compile-time slowdown for a large application. So this commit releases unused ConstantArrays only. rdar://19040716. It reduces memory footprint from 20+G to 6+G. llvm-svn: 226592
* Use the DiagnosticHandler to print diagnostics when reading bitcode.Rafael Espindola2015-01-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Linker: Don't use MDNode::replaceOperandWith()Duncan P. N. Exon Smith2015-01-071-11/+21
| | | | | | | | | | | `MDNode::replaceOperandWith()` changes all instances of metadata. Stop using it when linking module flags, since (due to uniquing) the flag values could be used by other metadata. Instead, use new API `NamedMDNode::setOperand()` to update the reference directly. llvm-svn: 225397
* Finish removing DestroySource.Rafael Espindola2014-12-231-1/+1
| | | | | | Fixes pr21901. llvm-svn: 224782
* Rename MapValue(Metadata*) to MapMetadata()Duncan P. N. Exon Smith2014-12-191-3/+3
| | | | | | | | Instead of reusing the name `MapValue()` when mapping `Metadata`, use `MapMetadata()`. The old name doesn't make much sense after the `Metadata`/`Value` split. llvm-svn: 224566
* Reapply "Linker: Drop superseded subprograms"Duncan P. N. Exon Smith2014-12-181-0/+54
| | | | | | | | | | | | | | | | | | | | This reverts commit r224416, reapplying r224389. The buildbots hadn't recovered after my revert, waiting until David reverted a couple of his commits. It looks like it was just bad timing (where we were both modifying code related to the same assertion). Trying again... Here's the original text: When a function gets replaced by `ModuleLinker`, drop superseded subprograms. This ensures that the "first" subprogram pointing at a function is the same one that `!dbg` references point at. This is a stop-gap fix for PR21910. Notably, this fixes Release+Asserts bootstraps that are currently asserting out in `LexicalScopes::initialize()` due to the explicit instantiations in `lib/IR/Dominators.cpp` eventually getting replaced by -argpromotion. llvm-svn: 224487
* Revert "Linker: Drop superseded subprograms"Duncan P. N. Exon Smith2014-12-171-54/+0
| | | | | | | | | | | | | | This reverts commit r224389. Based on feedback from the bots, the assertion seems to be going off *more* often, not less (previously I was just seeing it in an internal bootstrap, now it's happening in public builds too). http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/936/ http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/5325 Reverting in order to investigate. llvm-svn: 224416
* Linker: Drop superseded subprogramsDuncan P. N. Exon Smith2014-12-161-0/+54
| | | | | | | | | | | | | When a function gets replaced by `ModuleLinker`, drop superseded subprograms. This ensures that the "first" subprogram pointing at a function is the same one that `!dbg` references point at. This is a stop-gap fix for PR21910. Notably, this fixes Release+Asserts bootstraps that are currently asserting out in `LexicalScopes::initialize()` due to the explicit instantiations in `lib/IR/Dominators.cpp` eventually getting replaced by -argpromotion. llvm-svn: 224389
* Make the assert a bit stronger.Rafael Espindola2014-12-161-2/+1
| | | | | | We should get no declarations in here. llvm-svn: 224382
* Sink the isa into the assertMichael Ilseman2014-12-151-4/+2
| | | | llvm-svn: 224291
* Clean up warning about unused variableMichael Ilseman2014-12-151-2/+4
| | | | llvm-svn: 224281
* Revert of r223763, in spirit.Michael Ilseman2014-12-151-2/+1
| | | | | | | | r223763 was made to work around a temporary issue where a user of the JIT was passing down a declaration (incorrectly). This shouldn't occur, so assert rather than silently continue. llvm-svn: 224277
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-19/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Skip declarations in the case of functions.Michael Ilseman2014-12-091-0/+3
| | | | | | | | This is a revert of r223521 in spirit, if not in content. I am not sure why declarations ended up in LazilyLinkGlobalValues in the first place; that will take some more investigation. llvm-svn: 223763
* Lazily link GlobalVariables and GlobalAliases.Rafael Espindola2014-12-081-119/+125
| | | | | | | | | | | We were already lazily linking functions, but all GlobalValues can be treated uniformly for this. The test updates are to ensure that a given GlobalValue is still linked in. This fixes pr21494. llvm-svn: 223681
* Don't crash when the key of a comdat is lazily linked.Rafael Espindola2014-12-081-0/+9
| | | | llvm-svn: 223673
* Move the ValueMap lookup inside linkFunctionBody. NFC.Rafael Espindola2014-12-081-16/+15
| | | | llvm-svn: 223659
* Use range loops. NFC.Rafael Espindola2014-12-081-10/+9
| | | | llvm-svn: 223658
* Use range loops. NFC.Rafael Espindola2014-12-081-12/+10
| | | | llvm-svn: 223657
* Fix linking of prologue data.Rafael Espindola2014-12-081-18/+11
| | | | | | It would crash when the function was lazy linked. llvm-svn: 223656
* Simple style fixes.Rafael Espindola2014-12-081-14/+15
| | | | | | | | * Use a range loop. * Move simple continue checks earlier. * clang-format. llvm-svn: 223654
* Move materialize/Dematerialize calls to linkFunctionBody. NFC.Rafael Espindola2014-12-081-15/+12
| | | | | | Just less code duplication. llvm-svn: 223653
* Turn some DenseMaps that are only used for set operations into DenseSets.Benjamin Kramer2014-12-061-4/+3
| | | | | | DenseSet has better memory efficiency now. llvm-svn: 223589
* Remove dead code. We are only lazy about functions with bodies.Rafael Espindola2014-12-051-7/+1
| | | | llvm-svn: 223521
* Simplify the loop linking function bodies. NFC.Rafael Espindola2014-12-051-37/+21
| | | | llvm-svn: 223512
* Remove unused arguments. NFC.Rafael Espindola2014-12-051-9/+7
| | | | llvm-svn: 223503
* Refactor duplicated code. NFC.Rafael Espindola2014-12-051-26/+16
| | | | llvm-svn: 223486
* Small cleanup on how we clear constant variables. NFC.Rafael Espindola2014-12-051-14/+9
| | | | llvm-svn: 223474
* Use an early return. NFC.Rafael Espindola2014-12-051-19/+19
| | | | llvm-svn: 223470
* linkGlobalVariableProto never returns null. Simplify the caller. NFC.Rafael Espindola2014-12-051-6/+3
| | | | llvm-svn: 223424
* Move merging of alignment to a central location. NFC.Rafael Espindola2014-12-051-19/+3
| | | | llvm-svn: 223418
* Split the set of identified struct types into opaque and non-opaque ones.Rafael Espindola2014-12-031-106/+201
| | | | | | | | | | | | | | | | | | | The non-opaque part can be structurally uniqued. To keep this to just a hash lookup, we don't try to unique cyclic types. Also change the type mapping algorithm to be optimistic about a type not being recursive and only create a new type when proven to be wrong. This is not as strong as trying to speculate that we can keep the source type, but is simpler (no speculation to revert) and more powerfull than what we had before (we don't copy non-recursive types at least). I initially wrote this to try to replace the name based type merging. It is not strong enough to replace it, but is is a useful addition. With this patch the number of named struct types is a clang lto bootstrap goes from 49674 to 15986. llvm-svn: 223278
* Ask the module for its the identified types.Rafael Espindola2014-12-031-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When lazy reading a module, the types used in a function will not be visible to a TypeFinder until the body is read. This patch fixes that by asking the module for its identified struct types. If a materializer is present, the module asks it. If not, it uses a TypeFinder. This fixes pr21374. I will be the first to say that this is ugly, but it was the best I could find. Some of the options I looked at: * Asking the LLVMContext. This could be made to work for gold, but not currently for ld64. ld64 will load multiple modules into a single context before merging them. This causes us to see types from future merges. Unfortunately, MappedTypes is not just a cache when it comes to opaque types. Once the mapping has been made, we have to remember it for as long as the key may be used. This would mean moving MappedTypes to the Linker class and having to drop the Linker::LinkModules static methods, which are visible from C. * Adding an option to ignore function bodies in the TypeFinder. This would fix the PR by picking the worst result. It would work, but unfortunately we are currently quite dependent on the upfront type merging. I will try to reduce our dependency, but it is not clear that we will be able to get rid of it for now. The only clean solution I could think of is making the Module own the types. This would have other advantages, but it is a much bigger change. I will propose it, but it is nice to have this fixed while that is discussed. With the gold plugin, this patch takes the number of types in the LTO clang binary from 52817 to 49669. llvm-svn: 223215
* Prologue supportPeter Collingbourne2014-12-031-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
* Use a continue to reduce indentation and clang-format. NFC.Rafael Espindola2014-12-011-21/+24
| | | | llvm-svn: 223067
* Use a range loop. NFC.Rafael Espindola2014-12-011-3/+3
| | | | llvm-svn: 223066
* Drop SrcStructTypesSet. It is redundant.Rafael Espindola2014-12-011-3/+1
| | | | | | | At the only point in the code it is used, we haven't added any of the src types to DstStructTypesSet yet. llvm-svn: 223057
* Partial revert of r222986.Rafael Espindola2014-12-011-5/+20
| | | | | | | | | | The explicit set of destination types is not fully redundant when lazy loading since the TypeFinder will not find types used only in function bodies. This keeps the logic to drop the name of mapped types since it still helps with avoiding further renaming. llvm-svn: 223043
* Change how we keep track of which types are in the dest module.Rafael Espindola2014-12-011-13/+10
| | | | | | | | | | Instead of keeping an explicit set, just drop the names of types we choose to map to some other type. This has the advantage that the name of the unused will not cause the context to rename types on module read. llvm-svn: 222986
* Add back r222727 with a fix.Rafael Espindola2014-11-281-3/+13
| | | | | | | | | | | | | | | | | | | | | The original patch would fail when: * A dst opaque type (%A) is matched with a src type (%A). * A src opaque (%E) type is then speculatively matched with %A and the speculation fails afterward. * When rolling back the speculation we would cancel the source %A to dest %A mapping. The fix is to keep an explicit list of which resolutions are speculative. Original message: Fix overly aggressive type merging. If we find out that two types are *not* isomorphic, we learn nothing about opaque sub types in both the source and destination. llvm-svn: 222923
* Add an assert and use a range loop. NFC.Rafael Espindola2014-11-281-2/+4
| | | | llvm-svn: 222922
* Revert "Fix overly aggressive type merging."Duncan P. N. Exon Smith2014-11-271-19/+8
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r222727, which causes LTO bootstrap failures. Last passing @ r222698: http://lab.llvm.org:8080/green/job/clang-Rlto_master_build/532/ First failing @ r222843: http://lab.llvm.org:8080/green/job/clang-Rlto_master_build/533/ Internal bootstraps pointed at a much narrower range: r222725 is passing, and r222731 is failing. LTO crashes while handling libclang.dylib: http://lab.llvm.org:8080/green/job/clang-Rlto_master_build/533/consoleFull#-158682280549ba4694-19c4-4d7e-bec5-911270d8a58c GEP is not of right type for indices! %InfoObj.i.i = getelementptr inbounds %"class.llvm::OnDiskIterableChainedHashTable"* %.lcssa, i64 0, i32 0, i32 4, !dbg !123627 %"class.clang::serialization::reader::ASTIdentifierLookupTrait" = type { %"class.clang::ASTReader.31859"*, %"class.clang::serialization::ModuleFile.31870"*, %"class.clang::IdentifierInfo"* }LLVM ERROR: Broken function found, compilation aborted! clang: error: linker command failed with exit code 1 (use -v to see invocation) Looks like the new algorithm doesn't merge types aggressively enough. llvm-svn: 222895
* Set the body of a new struct as soon as it is created.Rafael Espindola2014-11-251-47/+22
| | | | | | | | | | | | | | | This changes the order in which different types are passed to get, but one order is not inherently better than the other. The main motivation is that this simplifies linkDefinedTypeBodies now that it is only linking "real" opaque types. It is also means that we only have to call it once and that we don't need getImpl. A small change in behavior is that we don't copy type names when resolving opaque types. This is an improvement IMHO, but it can be added back if desired. A test is included with the new behavior. llvm-svn: 222764
OpenPOWER on IntegriCloud