summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Linker/IRMover.cpp
Commit message (Collapse)AuthorAgeFilesLines
* IRMover: Merge flags LinkModuleInlineAsm and IsPerformingImport.Peter Collingbourne2017-02-031-10/+11
| | | | | | | | | Currently these flags are always the inverse of each other, so there is no need to keep them separate. Differential Revision: https://reviews.llvm.org/D29471 llvm-svn: 294016
* Linker: Move special casing for available_externally in IRMover to clients. ↵Peter Collingbourne2017-02-021-3/+0
| | | | | | | | | | NFCI. The goal is to simplify the semantic model for clients of IRMover. Differential Revision: https://reviews.llvm.org/D29435 llvm-svn: 293864
* [ThinLTO] Import only necessary DICompileUnit fieldsTeresa Johnson2016-12-121-3/+73
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed on mailing list, for ThinLTO importing we don't need to import all the fields of the DICompileUnit. Don't import enums, macros, retained types lists. Also only import local scoped imported entities. Since we don't currently import any global variables, we also don't need to import the list of global variables (added an assert to verify none are being imported). This is being done by pre-populating the value map entries to map the unneeded metadata to nullptr. For the imported entities, we can simply replace the source module's list with a new list containing only those needed imported entities. This is done in the IRLinker constructor so that value mapping automatically does the desired mapping. Reviewers: mehdi_amini, dexonsmith, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27635 llvm-svn: 289441
* IR: Move NumElements field from {Array,Vector}Type to SequentialType.Peter Collingbourne2016-12-021-5/+3
| | | | | | | | | | Now that PointerType is no longer a SequentialType, all SequentialTypes have an associated number of elements, so we can move that information to the base class, allowing for a number of simplifications. Differential Revision: https://reviews.llvm.org/D27122 llvm-svn: 288464
* [ThinLTO] Fix crash when importing an opaque typeMehdi Amini2016-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It seems that because ThinLTO does not import the full module, some invariant of the type mapper are broken. In Monolithic LTO, we import every globals: when calling IRLinker::copyFunctionProto() on @foo(), we end-up calling TypeMapTy::get(FTy) on the type of @foo(), which will map %0 and record the destination as opaque. ThinLTO skips this because @foo is not imported and goes directly to the next stage. Next we call computeTypeMapping() that map the types for each globals, and ends up checking for type isomorphism, and may add type mapping. However it doesn't record if there was an opaque destination type that was resolved. Instead of lazily "discovering" opaque type in the destination module on the go, we change the TypeFinder to eagerly record all types and not only the named ones. Differential Revision: https://reviews.llvm.org/D26840 llvm-svn: 287453
* IRMover: Avoid accidentally mapping types from the destination module (PR30799)Hans Wennborg2016-11-181-0/+8
| | | | | | | | | | | | | | During Module linking, it's possible for SrcM->getIdentifiedStructTypes(); to return types that are actually defined in the destination module (DstM). Depending on how the bitcode file was read, getIdentifiedStructTypes() might do a walk over all values, including metadata nodes, looking for types. In my case, a debug info metadata node was shared between the two modules, and it referred to a type defined in the destination module (see test case). Differential Revision: https://reviews.llvm.org/D26212 llvm-svn: 287353
* Linker: Remove unnecessary call to copyMetadata in IRLinker::linkGlobalVariable.Peter Collingbourne2016-11-141-2/+0
| | | | | | | | | | | This was causing us to create duplicate metadata on global variables. Debug info test case by Adrian Prantl, additional test cases by me. Fixes PR31012. Differential Revision: https://reviews.llvm.org/D26622 llvm-svn: 286905
* TypoAdrian Prantl2016-11-141-1/+1
| | | | llvm-svn: 286845
* Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne2016-11-091-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
* Typo: nomed struct -> named structHans Wennborg2016-10-191-1/+1
| | | | llvm-svn: 284635
* [ThinLTO] Don't link module level assembly when importingTeresa Johnson2016-10-121-5/+14
| | | | | | | | | | | | | | | | | | | | | Module inline asm was always being linked/concatenated when running the IRLinker. This is correct for full LTO but not when we are importing for ThinLTO, as it can result in multiply defined symbols when the module asm defines a global symbol. In order to test with llvm-lto2, I had to work around PR30396, where a symbol that is defined in module assembly but defined in the LLVM IR appears twice. Added workaround to llvm-lto2 with a FIXME. Fixes PR30610. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25359 llvm-svn: 284030
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-3/+5
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* Fix ThinLTO crash with debug infoMehdi Amini2016-09-031-0/+6
| | | | | | | | | | | | Because the recent change about ODR type uniquing in the context, we can reach types defined in another module during IR linking. This triggered some assertions in case we IR link without starting from an empty module. To alleviate that, we can self-map metadata defined in the destination module so that they won't be visited. Differential Revision: https://reviews.llvm.org/D23841 llvm-svn: 280599
* Linker: Avoid some ridiculous indentation by using a temporary. NFCJustin Bogner2016-08-151-12/+11
| | | | | | | This was indented really awkwardly, and clang-format didn't seem to know how to do any better. Avoid the issue with a temporary variable. llvm-svn: 278756
* Use the range variant of remove_if instead of unpacking begin/endDavid Majnemer2016-08-121-9/+9
| | | | | | No functionality change is intended. llvm-svn: 278475
* IR: New representation for CFI and virtual call optimization pass metadata.Peter Collingbourne2016-06-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than being directly associated with a global. This makes it harder to manipulate the metadata when rebuilding global variables, summarise it as part of ThinLTO and drop unused metadata when associated globals are dropped. For this reason, CFI does not currently work correctly when both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable globals, and fails to associate metadata with the rebuilt globals. As I understand it, the same problem could also affect ASan, which rebuilds globals with a red zone. This patch solves both of those problems in the following way: 1. Rename the metadata to "type metadata". This new name reflects how the metadata is currently being used (i.e. to represent type information for CFI and vtable opt). The new name is reflected in the name for the associated intrinsic (llvm.type.test) and pass (LowerTypeTests). 2. Attach metadata directly to the globals that it pertains to, rather than using the "llvm.bitsets" global metadata node as we are doing now. This is done using the newly introduced capability to attach metadata to global variables (r271348 and r271358). See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21053 llvm-svn: 273729
* Linker: Copy metadata when linking declarations.Peter Collingbourne2016-06-241-4/+7
| | | | | | Differential Revision: http://reviews.llvm.org/D21624 llvm-svn: 273692
* Remangle intrinsics names when types are renamedArtur Pilipenko2016-06-241-0/+9
| | | | | | | | | | | | | This is a resubmittion of previously reverted rL273568. This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273686
* Revert r273568 "Remangle intrinsics names when types are renamed"Hans Wennborg2016-06-231-9/+0
| | | | | | It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll llvm-svn: 273574
* Remangle intrinsics names when types are renamedArtur Pilipenko2016-06-231-0/+9
| | | | | | | | | | | This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273568
* [IR] [DAE] Copy comdats during DAE, and don't copy comdats in ↵Justin Lebar2016-06-151-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | GlobalObject::copyAttributesFrom. Summary: This reverts the changes to Globals.cpp and IRMover.cpp in "[IR] Copy comdats in GlobalObject::copyAttributesFrom" (D20631, rL270743). The DeadArgElim test is left unchanged, and we change DAE to explicitly copy comdats. The reverted change breaks copyAttributesFrom when the destination lives in a different module from the source. The decision in D21255 was to revert this patch and handle comdat copying separately from copyAttributesFrom. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21403 llvm-svn: 272855
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Move instances of std::function.Benjamin Kramer2016-06-121-1/+1
| | | | | | Or replace with llvm::function_ref if it's never stored. NFC intended. llvm-svn: 272513
* [Linker/IRMover] Simplify the code a bit. NFCI.Davide Italiano2016-06-071-25/+7
| | | | llvm-svn: 272013
* Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer2016-05-271-2/+4
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270997
* Linker: teach the IR mover to return llvm::Error.Peter Collingbourne2016-05-271-95/+84
| | | | | | | | | This will be needed in order to consistently return an Error to clients of the API being developed in D20268. Differential Revision: http://reviews.llvm.org/D20550 llvm-svn: 270967
* ValueMaterializer: rename materializeDeclFor() to materialize()Mehdi Amini2016-05-251-4/+4
| | | | | | | | | | It may materialize a declaration, or a definition. The name could be misleading. This is following a merge of materializeInitFor() into materializeDeclFor(). Differential Revision: http://reviews.llvm.org/D20593 llvm-svn: 270759
* ValueMaterializer: fuse materializeDeclFor and materializeInitFor (NFC)Mehdi Amini2016-05-251-30/+22
| | | | | | | | | | | | They were originally separated to handle the co-recursion between the ValueMapper and the ValueMaterializer. This recursion does not exist anymore: the ValueMapper now uses a Worklist and the ValueMaterializer is scheduling job on the Worklist. Differential Revision: http://reviews.llvm.org/D20593 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 270758
* IRLinker: fix double scheduling of mapping a global value because of an aliasMehdi Amini2016-05-251-0/+11
| | | | | | | | | | | | This test was hitting an assertion in the value mapper because the IRLinker was trying to map two times @A while materializing the initializer for @C. Fix http://llvm.org/PR27850 Differential Revision: http://reviews.llvm.org/D20586 llvm-svn: 270757
* [IR] Copy comdats in GlobalObject::copyAttributesFromReid Kleckner2016-05-251-0/+5
| | | | | | | | | | | | | | This is probably correct for all uses except cross-module IR linking, where we need to move the comdat from the source module to the destination module. Fixes PR27870. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D20631 llvm-svn: 270743
* Return a StringRef from getSection.Rafael Espindola2016-05-111-1/+1
| | | | | | This is similar to how getName is handled. llvm-svn: 269218
* Fix recursive -only-needed.Rafael Espindola2016-04-211-1/+3
| | | | | | We were assuming that only linkonce_odr GVs were lazy linked. llvm-svn: 266995
* Linker: Avoid constructing ValueMap::MDMapTDuncan P. N. Exon Smith2016-04-191-2/+2
| | | | | | | | | Calling ValueMap::MD lazily constructs a ValueMap, which mallocs the buckets. Instead of swapping constructed maps, move around the underlying Optional<MDMapT>. This gets rid of some unnecessary malloc traffic from r266579 (not that it showed up on a profile). llvm-svn: 266761
* ModuleLinker: Do not import linkonce/weak as "external_weak"Mehdi Amini2016-04-191-2/+1
| | | | | | | | | | | | | | | Summary: There is no reason to have a weak reference because the external definition will be weak. Reviewers: rafael Subscribers: llvm-commits, tejohnson Differential Revision: http://reviews.llvm.org/D19267 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266750
* Linker: Share a single Metadata map for the lifetime of IRMoverDuncan P. N. Exon Smith2016-04-171-5/+14
| | | | | | | | | | Cache the result of mapping metadata nodes between instances of IRLinker (i.e., for the lifetime of IRMover). There shouldn't be any real functional change here, but this should give a major speedup. I had loaned this to Mehdi when he tested performance of r266446, and the two patches together gave a 10x speedup in metadata mapping. llvm-svn: 266579
* Linker: Don't double-schedule appending variablesDuncan P. N. Exon Smith2016-04-171-1/+1
| | | | | | | | | | | | | Add an assertion to ValueMapper that prevents double-scheduling of GlobalValues to remap, and fix the one place it happened. There are tons of tests that fail with this assertion in place and without the code change, so I'm not adding another. Although it looks related, r266563 was, indeed, removing dead code. AFAICT, this cross-file double-scheduling started in r266510 when the cross-file recursion was removed. llvm-svn: 266569
* IRMover: Remove dead code, NFCDuncan P. N. Exon Smith2016-04-171-3/+0
| | | | llvm-svn: 266563
* Reapply "ValueMapper: Eliminate cross-file co-recursion, NFC"Duncan P. N. Exon Smith2016-04-161-38/+24
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit r266507, reapplying r266503 (and r266505 "ValueMapper: Use API from r266503 in unit tests, NFC") completely unchanged. I reverted because of a bot failure here: http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16810/ However, looking more closely, the failure was from a host-compiler crash (clang 3.7.1) when building: lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/DwarfAccelTable.cpp.o I didn't modify that file, or anything it includes, with that commit. The next build (which hadn't picked up my revert) got past it: http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16811/ I think this was just unfortunate timing. I suppose the bot must be flakey. llvm-svn: 266510
* Revert "ValueMapper: Eliminate cross-file co-recursion, NFC"Duncan P. N. Exon Smith2016-04-161-24/+38
| | | | | | | | | | | | This reverts commit r266503, in case it's the root cause of this bot failure: http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/16810 I'm also reverting r266505 -- "ValueMapper: Use API from r266503 in unit tests, NFC" -- since it's in the way. llvm-svn: 266507
* ValueMapper: Eliminate cross-file co-recursion, NFCDuncan P. N. Exon Smith2016-04-161-38/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Eliminate co-recursion of Mapper::mapValue through ValueMaterializer::materializeInitFor, through a major redesign of the ValueMapper.cpp interface. - Expose a ValueMapper class that controls the entry points to the mapping algorithms. - Change IRLinker to use ValueMapper directly, rather than llvm::RemapInstruction, llvm::MapValue, etc. - Use (e.g.) ValueMapper::scheduleMapGlobalInit to add mapping work to a worklist in ValueMapper instead of recursing. There were two fairly major complications. Firstly, IRLinker::linkAppendingVarProto incorporates an on-the-fly IR ugprade that I had to split apart. Long-term, this upgrade should be done in the bitcode reader (and we should only accept the "new" form), but for now I've just made it work and added a FIXME. The hold-op is that we need to deprecate C API that relies on this. Secondly, IRLinker has special logic to correctly implement aliases with comdats, and uses two ValueToValueMapTy instances and two ValueMaterializers. I supported this by allowing clients to register an alternate mapping context, whose MCID can be passed in when scheduling new work. While out of scope for this commit, it should now be straightforward to remove recursion from Mapper::mapValue. llvm-svn: 266503
* Linker: Remove an unnecessary local variable in for loop, NFCDuncan P. N. Exon Smith2016-04-151-6/+4
| | | | | | Reduces changes in a follow-up commit. llvm-svn: 266493
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-71/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* ValueMapper: Extract llvm::RemapFunction from IRMover.cpp, NFCDuncan P. N. Exon Smith2016-04-081-25/+8
| | | | | | | | | | | | | | Strip out the remapping parts of IRLinker::linkFunctionBody and put them in ValueMapper.cpp under the name Mapper::remapFunction (with a top-level entry-point llvm::RemapFunction). This is a nice cleanup on its own since it puts the remapping code together and shares a single Mapper context for the entire IRLinker::linkFunctionBody Call. Besides that, this will make it easier to break the co-recursion between IRMover.cpp and ValueMapper.cpp in follow ups. llvm-svn: 265835
* Linker: Always pass RF_IgnoreMissingLocals; NFCDuncan P. N. Exon Smith2016-04-081-3/+3
| | | | | | | | | | | This is a cleanup after clarifying the meaning of RF_IgnoreMissingLocals in r265628 and truly limiting it to locals in r265768. This should have no functionality change, since the only context that the flag has an effect is when we could hit function-local Value and Metadata, and we were already passing it in those contexts. llvm-svn: 265831
* IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFCDuncan P. N. Exon Smith2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Clarify what this RemapFlag actually means. - Change the flag name to match its intended behaviour. - Clearly document that it's not supposed to affect globals. - Add a host of FIXMEs to indicate how to fix the behaviour to match the intent of the flag. RF_IgnoreMissingLocals should only affect the behaviour of RemapInstruction for function-local operands; namely, for operands of type Argument, Instruction, and BasicBlock. Currently, it is *only* passed into RemapInstruction calls (and the transitive MapValue calls that it makes). When I split Metadata from Value I didn't understand the flag, and I used it in a bunch of places for "global" metadata. This commit doesn't have any functionality change, but prepares to cleanup MapMetadata and MapValue. llvm-svn: 265628
* IRMover: Steal arguments when moving functions, NFCDuncan P. N. Exon Smith2016-04-061-19/+6
| | | | | | | | | | | | | | | | | | Instead of copying arguments from the source function to the destination, steal them. This has a few advantages. - The ValueMap doesn't need to be seeded with (or cleared of) Arguments. - Often the destination function won't have created any arguments yet, so this avoids malloc traffic. - Argument names don't need to be copied. Because argument lists are lazy, this required a new Function::stealArgumentListFrom helper. llvm-svn: 265519
* Linker: Split mapUnneededSubprograms into two; almost NFCDuncan P. N. Exon Smith2016-04-021-11/+15
| | | | | | | | | | | | | | Split the loop through compile units in mapUnneededSubprograms in two. First, visit imported entities to ensure that we've visited all need subprograms. Second, visit subprograms, and drop the ones we don't need. Hypothetically this protects against a subprogram from one compile unit being referenced from an imported entity in a different compile unit. I don't think that's valid IR (a debug info expert could confirm), but I think the refactor makes the code more clear. llvm-svn: 265233
* Remove redundant assertion after cast, NFCDuncan P. N. Exon Smith2016-04-021-1/+0
| | | | llvm-svn: 265232
* Linker: Avoid unnecessary work when moving named metadataDuncan P. N. Exon Smith2016-04-021-17/+11
| | | | | | | | | | | IRLinker::mapUnneededSubprograms has to be sure that any "needed" subprograms get linked in. Rather than traversing through imported entities using llvm::getSubprogram, call MapMetadata. The latter memoizes the result in the ValueMap (sharing work with IRLinker::linkNamedMDNodes proper), and makes the local SmallPtrSet redundant. llvm-svn: 265231
* Linker: Remove IRMover::isMetadataUnneeded indirection; almost NFCDuncan P. N. Exon Smith2016-04-021-48/+19
| | | | | | | | | | | | | | | | Instead of checking live during MapMetadata whether a subprogram is needed, seed the ValueMap with `nullptr` up-front. There is a small hypothetical functionality change. Previously, calling MapMetadataOp on a node whose "scope:" chain led to an unneeded subprogram would return nullptr. However, if that were ever called, then the subprogram would be needed; a situation that the IRMover is supposed to avoid a priori! Besides cleaning up the code a little, this restores a nice property: MapMetadataOp returns the same as MapMetadata. llvm-svn: 265229
OpenPOWER on IntegriCloud