summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils/ValueMapper.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Teach ValueMapper to use ODR uniqued types when availableTeresa Johnson2018-01-301-4/+15
| | | | | | | | | | | | | | | | | Summary: This is exposed during ThinLTO compilation, when we import an alias by creating a clone of the aliasee. Without this fix the debug type is unnecessarily cloned and we get a duplicate, undoing the uniquing. Fixes PR36089. Reviewers: mehdi_amini, pcc Subscribers: eraman, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D41669 llvm-svn: 323813
* [Transforms] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-10-261-8/+31
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 316630
* Suppress all uses of LLVM_END_WITH_NULL. NFC.Serge Guelton2017-05-091-5/+4
| | | | | | | | | Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential Revision: https://reviews.llvm.org/D32541 llvm-svn: 302571
* Remap metadata attached to global variables.Evgeniy Stepanov2017-05-041-5/+12
| | | | | | | Fix for PR32577. Global variables may have !associated metadata, which includes a reference to another global. It needs remapping. llvm-svn: 302203
* "Use" lambda captures which are otherwise only used in asserts. NFCDavid L. Jones2017-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LLVM coding standards recommend "using" values that are only needed by asserts: http://llvm.org/docs/CodingStandards.html#assert-liberally Without this change, LLVM cannot bootstrap with -Werror as the second stage fails with this new warning: https://reviews.llvm.org/rL291905 See also the previous fixes: https://reviews.llvm.org/rL291916 https://reviews.llvm.org/rL291939 https://reviews.llvm.org/rL291940 https://reviews.llvm.org/rL291941 Reviewers: rsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28695 llvm-svn: 291957
* Do a sweep over move ctors and remove those that are identical to the default.Benjamin Kramer2016-10-201-20/+0
| | | | | | | | | | All of these existed because MSVC 2013 was unable to synthesize default move ctors. We recently dropped support for it so all that error-prone boilerplate can go. No functionality change intended. llvm-svn: 284721
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-1/+1
| | | | | | No functionality change is intended. llvm-svn: 278417
* Delete more dead code.Rafael Espindola2016-06-221-30/+0
| | | | | | Found by gcc 6. llvm-svn: 273402
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-1/+2
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* ValueMapper: fix assertion when null-mapping a constant for linking metadataMehdi Amini2016-05-281-3/+17
| | | | | | | | | | | | | | | | Summary: When RF_NullMapMissingGlobalValues is set, mapValue can return null for GlobalValue. When mapping the operands of a constant that is referenced from metadata, we need to handle this case and actually return null instead of mapping this constant. Reviewers: dexonsmith, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D20713 llvm-svn: 271129
* ValueMapper: fix typo in minor optimization on constant mapping (NFC)Mehdi Amini2016-05-271-1/+2
| | | | | | | | | | | | | | | | | If every operands of a constant are mapping to themselves, and the type does not change, we have an early exit as acknowledged in the comment: // Otherwise, we have some other constant to remap. Start by checking to see // if all operands have an identity remapping. However instead of checking for identity the code was checking if the operands were mapped to the constant itself, which is rarely true. As a consequence, the coverage report showed that the early exit was never taken. llvm-svn: 270944
* ValueMaterializer: rename materializeDeclFor() to materialize()Mehdi Amini2016-05-251-3/+3
| | | | | | | | | | 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-7/+1
| | | | | | | | | | | | 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
* Minor code cleanups. NFC.Junmo Park2016-05-081-3/+3
| | | | llvm-svn: 268888
* ValueMapper/Enumerator: Clean up code in post-order traversals, NFCDuncan P. N. Exon Smith2016-04-221-51/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-layer the functions in the new (i.e., newly correct) post-order traversals in ValueEnumerator (r266947) and ValueMapper (r266949). Instead of adding a node to the worklist in a helper function and returning a flag to say what happened, return the node itself. This makes the code way cleaner: the worklist is local to the main function, there is no flag for an early loop exit (since we can cleanly bury the loop), and it's perfectly clear when pointers into the worklist might be invalidated. I'm fixing both algorithms in the same commit to avoid repeating the commit message; if you take the time to understand one the other should be easy. The diff itself isn't entirely obvious since the traversals have some noise (i.e., things to do), but here's the high-level change: auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) { => while (I != E) { if (shouldVisit(Op)) { T *Op = *I++; WL.push(Op, Op->begin()); if (shouldVisit(Op)) { return true; return Op; } } return false; return nullptr; }; }; => WL.push(S, S->begin()); WL.push(S, S->begin()); while (!empty()) { while (!empty()) { auto *N = WL.top().N; auto *N = WL.top().N; auto *&I = WL.top().I; auto *&I = WL.top().I; bool DidChange = false; while (I != N->end()) if (helper(*I++)) { => if (T *Op = helper(I, N->end()) { DidChange = true; WL.push(Op, Op->begin()); break; continue; } } if (DidChange) continue; POT.push(WL.pop()); => POT.push(WL.pop()); } } Thanks to Mehdi for helping me find a better way to layer this. llvm-svn: 267099
* ValueMapper: Map uniqued nodes in post-orderDuncan P. N. Exon Smith2016-04-211-32/+57
| | | | | | | | | | | | | | | The iteratitive algorithm from r265456 claimed but failed to create a post-order traversal. It had the same error that was fixed in the ValueEnumerator in r266947: now, instead of pushing all operands on the worklist at once, we pause whenever an operand gets pushed in order to go depth-first (I know, it sounds obvious). Sadly, I have no idea how to observe this from outside the algorithm and so I haven't written a test. The output should be the same; it should just use fewer temporary nodes now. I've added some comments that I hope make the current logic clear enough it's unlikely to regress. llvm-svn: 266949
* Linker: Don't double-schedule appending variablesDuncan P. N. Exon Smith2016-04-171-0/+9
| | | | | | | | | | | | | 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
* ValueMapper: Don't allow explicit null mappings of Values, NFCDuncan P. N. Exon Smith2016-04-171-1/+3
| | | | | | | | | As a follow-up to r123058, assert that there are no null mappings in the ValueMap instead of just ignoring them when they are there. There were a couple of accidental insertions in CloneFunction so I cleaned those up (caught by testcases). llvm-svn: 266565
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
* ValueMapper: Separate mapping of distinct and uniqued nodes (again)Duncan P. N. Exon Smith2016-04-161-220/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the result of a mapped distinct node is known up front, it's more efficient to map them separately from uniqued nodes. This commit pulls them out of the post-order traversal and stores them in a worklist to be remapped at the top-level. This is essentially reapplying r244181 ("ValueMapper: Rotate distinct node remapping algorithm") to the new iterative algorithm from r265456 ("ValueMapper: Rewrite Mapper::mapMetadata without recursion"). Now that the traversal logic only handles uniqued MDNodes, it's much simpler to inline it all into MDNodeMapper::createPOT (I've killed the MDNodeMapper::push and MDNodeMapper::tryToPop helpers and localized the traversal worklist). The resulting high-level algorithm for MDNodeMapper::map now looks like this: - Distinct nodes are immediately mapped and added to MDNodeMapper::DistinctWorklist using MDNodeMapper::mapDistinctNode. - Uniqued nodes are mapped via MDNodeMapper::mapTopLevelUniquedNode, which traverses the transitive uniqued subgraph of a node to calculate uniqued node mappings in bulk. - This is a simplified version of MDNodeMapper::map from before this commit (originally r265456) that doesn't traverse through any distinct nodes. - Distinct nodes are added to MDNodeMapper::DistinctWorklist via MDNodeMapper::mapDistinctNode. - This uses MDNodeMapper::createPOT to fill a MDNodeMapper::UniquedGraph (a post-order traversal and side table), UniquedGraph::propagateChanges to track which uniqued nodes need to change, and MDNodeMapper::mapNodesInPOT to create the uniqued nodes. - Placeholders for forward references are now only needed when there's a uniquing cycle (a cycle of uniqued nodes unbroken by distinct nodes). This is the key functionality change that we're reintroducing (from r244181). As of r265456, a temporary forward reference might be needed for any cycle that involved uniqued nodes. - After mapping the first node appropriately, MDNodeMapper::map works through MDNodeMapper::DistinctWorklist. For each distinct node, its operands are remapped with MDNodeMapper::mapDistinctNode and MDNodeMapper::mapTopLevelUniquedNode until all nodes have been mapped. Sadly there's nothing observable I can test here; no real functionality change, just a compile-time speedup from reduced malloc traffic. llvm-svn: 266537
* ValueMapper: Only put cyclic nodes into CyclicNodes, NFCIDuncan P. N. Exon Smith2016-04-161-2/+11
| | | | | | | | | | | As a minor fixup to r266258, only track nodes that needed a placeholder in CyclicNodes in MDNodeMapper::mapUniquedNodes. There should be no observable functionality change, just some local memory savings because CyclicNodes only needs to grow to accommodate nodes that are actually involved in cycles. (This was the original intent of r266258, or else the vector would have been called "ChangedNodes".) llvm-svn: 266536
* ValueMapper: Fix unused var warning. NFCSimon Atanasyan2016-04-161-0/+2
| | | | llvm-svn: 266529
* ValueMapper: Stop memoizing ConstantAsMetadataDuncan P. N. Exon Smith2016-04-161-9/+36
| | | | | | | | | | | | Stop memoizing ConstantAsMetadata in ValueMapper::mapMetadata. Now we have to recompute it, but these metadata aren't particularly common, and it restricts the lifetime of the Metadata map unnecessarily. (The motivation is that I have a patch which uses a single Metadata map for the lifetime of IRMover. Mehdi profiled r266446 with the patch applied and we saw a pretty big speedup in lib/Linker.) llvm-svn: 266513
* Reapply "ValueMapper: Eliminate cross-file co-recursion, NFC"Duncan P. N. Exon Smith2016-04-161-61/+303
| | | | | | | | | | | | | | | | | | | | | | | 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-303/+61
| | | | | | | | | | | | 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-61/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ValueMapper: Hide Mapper::VM behind an accessor, NFCDuncan P. N. Exon Smith2016-04-151-29/+32
| | | | | | | | | Change Mapper::VM to a pointer and add a `getVM()` accessor for it. While this has no functionality change, it minimizes the diff on an upcoming patch that allows switching between instances of ValueToValueMapTy on a single Mapper instance. llvm-svn: 266490
* [ValueMapper] Range-loopify to improve readability. NFC.Davide Italiano2016-04-141-3/+3
| | | | llvm-svn: 266350
* ValueMapper: Resolve cycles on the new nodesDuncan P. N. Exon Smith2016-04-131-2/+4
| | | | | | | | | | | | | | Fix a major bug from r265456. Although it's now much rarer, ValueMapper sometimes has to duplicate cycles. The might-transitively-reference-a-temporary counts don't decrement on their own when there are cycles, and you need to call MDNode::resolveCycles to fix it. r265456 was checking the input nodes to see if they were unresolved. This is useless; they should never be unresolved. Instead we should check the output nodes and resolve cycles on them. llvm-svn: 266258
* ValueMapper: Extract llvm::RemapFunction from IRMover.cpp, NFCDuncan P. N. Exon Smith2016-04-081-0/+30
| | | | | | | | | | | | | | 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
* ValueMapper: Always use Mapper::mapValue from remapInstruction, NFCIDuncan P. N. Exon Smith2016-04-081-2/+1
| | | | | | | | | | | | Use Mapper::mapValue instead of llvm::MapValue from Mapper::remapInstruction when mapping an incoming block for a PHINode (follow-up to r265832). This will implicitly pass along the Materializer argument, but when this code was added in r133513 there was no Materializer argument. I suspect this call to MapValue was just missed in r182776 since it's not observable (basic blocks can't be materialized, and they don't reference other values). llvm-svn: 265833
* ValueMapper: Roll RemapInstruction into Mapper, NFCDuncan P. N. Exon Smith2016-04-081-8/+11
| | | | | | | | | | | | Add Mapper::remapInstruction, move the guts of llvm::RemapInstruction into it, and use the same Mapper for most of the calls to MapValue and MapMetadata. There should be no functionality change here. I left off the call to MapValue that wasn't passing in a Materializer argument (for basic blocks of PHINodes). It shouldn't change functionality either, but I'm suspicious enough to commit separately. llvm-svn: 265832
* ValueMapper: Don't memoize metadata when RF_NoModuleLevelChangesDuncan P. N. Exon Smith2016-04-081-1/+1
| | | | | | | | | Prevent the Metadata side-table in ValueMap from growing unnecessarily when RF_NoModuleLevelChanges. As a drive-by, make ValueMap::hasMD, which apparently had no users until I used it here for testing, actually compile. llvm-svn: 265828
* ValueMapper: Stop memoizing MDStringsDuncan P. N. Exon Smith2016-04-081-2/+6
| | | | | | | | | | | | | | | Stop adding MDString to the Metadata section of the ValueMap in MapMetadata. It blows up the size of the map for no benefit, since we can always return quickly anyway. There is a potential follow-up that I don't think I'll push on right away, but maybe someone else is interested: stop checking for a pre-mapped MDString, and move the `isa<MDString>()` checks in Mapper::mapSimpleMetadata and MDNodeMapper::getMappedOp in front of the `VM.getMappedMD()` calls. While this would preclude explicitly remapping MDStrings it would probably be a little faster. llvm-svn: 265827
* Reapply "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-081-23/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r265765, reapplying r265759 after changing a call from LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug intrinsic operand may no longer be pointing at a local. http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/ The previous coommit message follows: -- This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265768
* Revert "ValueMapper: Treat LocalAsMetadata more like function-local Values"Duncan P. N. Exon Smith2016-04-081-60/+23
| | | | | | | | | | | | | This reverts commit r265759, since even this limited version breaks some bots: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696 This also reverts r265761 "ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFC", since I had trouble separating it from r265759. llvm-svn: 265765
* ValueMapper: Unduplicate RF_NoModuleLevelChanges check, NFCDuncan P. N. Exon Smith2016-04-081-8/+5
| | | | llvm-svn: 265761
* ValueMapper: Treat LocalAsMetadata more like function-local ValuesDuncan P. N. Exon Smith2016-04-081-16/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a partial re-commit -- maybe more of a re-implementation -- of r265631 (reverted in r265637). This makes RF_IgnoreMissingLocals behave (almost) consistently between the Value and the Metadata hierarchy. In particular: - MapValue returns nullptr or "metadata !{}" for missing locals in MetadataAsValue/LocalAsMetadata bridging paris, depending on the RF_IgnoreMissingLocals flag. - MapValue doesn't memoize LocalAsMetadata-related results. - MapMetadata no longer deals with LocalAsMetadata or RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but I realized during testing it would make the patch simpler with no loss of generality.) r265631 went too far, making both functions universally ignore RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt. Reassociate (and possibly other passes) don't currently maintain dominates-use invariants for metadata operands, resulting in IR like this: define void @foo(i32 %arg) { call void @llvm.some.intrinsic(metadata i32 %x) %x = add i32 1, i32 %arg } If the inliner chooses to inline @foo into another function, then RemapInstruction will call `MapValue(metadata i32 %x)` and assert that the return is not nullptr. I've filed PR27273 to add a Verifier check and fix the underlying problem in the optimization passes. As a workaround, return `!{}` instead of nullptr for unmapped LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match the behaviour of r265631. Original commit message: ValueMapper: Make LocalAsMetadata match function-local Values Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265759
* Revert "ValueMapper: Make LocalAsMetadata match function-local Values"Duncan P. N. Exon Smith2016-04-071-38/+16
| | | | | | | | | | | This reverts commit r265631, since it caused bot failures: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3256 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/7272 Looks like something is depending on the old behaviour. I'll try to track it down and recommit. llvm-svn: 265637
* ValueMapper: Allow RF_IgnoreMissingLocals and RF_NullMapMissingGlobalValuesDuncan P. N. Exon Smith2016-04-071-7/+1
| | | | | | | | | Remove the assertion that disallowed the combination, since RF_IgnoreMissingLocals should have no effect on globals. As it happens, RF_NullMapMissingGlobalValues asserted in MapValue(Constant*,...), so I also changed a cast to a cast_or_null to get my test passing. llvm-svn: 265633
* ValueMapper: Make LocalAsMetadata match function-local ValuesDuncan P. N. Exon Smith2016-04-071-16/+38
| | | | | | | | | | | | | Start treating LocalAsMetadata similarly to function-local members of the Value hierarchy in MapValue and MapMetadata. - Don't memoize them. - Return nullptr if they are missing. This also cleans up ConstantAsMetadata to stop listening to the RF_IgnoreMissingLocals flag. llvm-svn: 265631
* IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFCDuncan P. N. Exon Smith2016-04-071-6/+16
| | | | | | | | | | | | | | | | | | | | | | | 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
* ValueMapper: Fix delayed blockaddress handling after r265273Duncan P. N. Exon Smith2016-04-061-3/+3
| | | | | | | | | r265273 added Mapper::mapBlockAddress, which delays mapping a blockaddress value until the function has a body. The condition was backwards, and should be checking Function::empty instead of GlobalValue::isDeclaration. llvm-svn: 265508
* Try harder to appease MSVC after r265456Duncan P. N. Exon Smith2016-04-051-3/+12
| | | | | | r265465 wasn't good enough. I need to spell out all the moves. llvm-svn: 265470
* Try to appease MSVC after r265456Duncan P. N. Exon Smith2016-04-051-0/+4
| | | | | | | I can't remember if adding `= default` will make MSVC happy, or if I have to spell this out. Let's try the cleaner version first. llvm-svn: 265465
* ValueMapper: Rewrite Mapper::mapMetadata without recursionDuncan P. N. Exon Smith2016-04-051-108/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit completely rewrites Mapper::mapMetadata (the implementation of llvm::MapMetadata) using an iterative algorithm. The guts of the new algorithm are in MDNodeMapper::map, the entry function in a new class. Previously, Mapper::mapMetadata performed a recursive exploration of the graph with eager "just in case there's a reason" malloc traffic. The new algorithm has these benefits: - New nodes and temporaries are not created eagerly. - Uniquing cycles are not duplicated (see new unit test). - No recursion. Given a node to map, it does this: 1. Use a worklist to perform a post-order traversal of the transitively referenced unmapped nodes. 2. Track which nodes will change operands, and which will have new addresses in the mapped scheme. Propagate the changes through the POT until fixed point, to pick up uniquing cycles that need to change. 3. Map all the distinct nodes without touching their operands. If RF_MoveDistinctMetadata, they get mapped to themselves; otherwise, they get mapped to clones. 4. Map the uniqued nodes (bottom-up), lazily creating temporaries for forward references as needed. 5. Remap the operands of the distinct nodes. Mehdi helped me out by profiling this with -flto=thin. On his workload (importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed about 50% less to persistent memory, and made about 100x fewer calls to malloc. The speedup is less than I'd hoped. The profile mainly blames DenseMap lookups; perhaps there's a way to reduce them (e.g., by disallowing remapping of MDString). It would be nice to break the strange remaining recursion on the Value side: MapValue => materializeInitFor => RemapInstruction => MapValue. I think we could do this by having materializeInitFor return a worklist of things to be remapped. llvm-svn: 265456
* ValueMapper: Remove old FIXMEs; almost NFCDuncan P. N. Exon Smith2016-04-041-21/+1
| | | | | | | | | | | | | | | | | | | | | Remove a few old FIXMEs from the original commit of the Metadata/Value split in r223802. These are commented out assertions to the effect that calls between mapValue and mapMetadata never return nullptr. (The only behaviour change is that Mapper::mapSimpleMetadata memoizes the nullptr return.) When I originally rewrote the mapping code, I thought we could be stricter in the new metadata hierarchy and never return nullptr when RF_NullMapMissingGlobalValues was off. It's still not entirely clear to me why these assertions failed (a few months ago, I had a theory that I forgot to write down, but that's helping no one). Understood or not, I no longer see how these commented-out assertions would be useful. I'm relegating them to the annals of source control before making significant changes to ValueMapper.cpp. llvm-svn: 265282
* ValueMapper: Disallow metadata mapping recursion through mapValueDuncan P. N. Exon Smith2016-04-031-0/+5
| | | | | | | | | | | | | | | This adds an assertion to maintain the property from r265273. When Mapper::mapSimpleMetadata calls Mapper::mapValue, it should not find its way back to mapMetadataImpl. This guarantees that mapSimpleMetadata is not involved in any recursion. Since Mapper::mapValue calls out to arbitrary materializers, we need to save a bit on the ValueMap to make this assertion effective. There should be no functionality change here. This co-recursion should already have been impossible. llvm-svn: 265276
* Work around MSVC failure from r265273Duncan P. N. Exon Smith2016-04-031-0/+10
| | | | | | http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19726 llvm-svn: 265275
* ValueMapper: Avoid recursion in mapSimplifiedMetadata, NFCDuncan P. N. Exon Smith2016-04-031-9/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is to delay materializing GlobalValue initializers from Mapper::mapValue until Mapper::~Mapper. This effectively removes all recursion from mapSimplifiedMetadata, as promised in r265270. mapSimplifiedMetadata calls mapValue for ConstantAsMetadata nodes to find the mapped constant, and now it shouldn't be possible for mapValue to indirectly re-invoke mapMetadata. I'll add an assertion to that effect in a follow-up (separated so that the assertion can easily be reverted independently, if it comes to that). This a step toward a broader goal: converting Mapper::mapMetadataImpl from a recursive to an iterative algorithm. When a BlockAddress points at a BasicBlock inside an unmaterialized function body, we need to delay it until the function body is materialized in Mapper::~Mapper. This commit creates a temporary BasicBlock and returns a new BlockAddress, then RAUWs the BasicBlock once it is known. This situation should be extremely rare since a BlockAddress is usually used from within the function it's referencing (and BlockAddress itself is rare). There should be no observable functionality change. llvm-svn: 265273
OpenPOWER on IntegriCloud