summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
...
* [MemorySSA] Fix bug in CachingMemorySSAWalker::invalidateInfoGeoff Berry2016-04-221-11/+20
| | | | | | | | | | | | | | | | | | | | | Summary: CachingMemorySSAWalker::invalidateInfo was using IsCall to determine which cache map needed to be cleared of entries referring to the invalidated MemoryAccess, but there could also be entries referring to it in the other cache map (value entries, not key entries). This change just clears both tables to be conservatively correct. Also add a verifyRemoved() function, called when expensive checks (i.e. XDEBUG) are enabled to verify that the invalidated MemoryAccess object is not referenced in any of the caches. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19388 llvm-svn: 267157
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-3/+3
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* 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
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-3/+3
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* [LoopUtils] Fix typo in commentAdam Nemet2016-04-211-1/+1
| | | | llvm-svn: 267016
* [LoopUtils] Add asserts to findStringMetadataForLoop. NFCAdam Nemet2016-04-211-0/+5
| | | | | | | These ensure that operand array has at least one element and it is the self-reference. llvm-svn: 267015
* [LoopUtils] Move def of findStringMetadataForLoop to LoopUtils.cpp. NFCAdam Nemet2016-04-211-0/+22
| | | | | | | The decl is in LoopUtils.h. I think that this was added to LoopVersioningLICM.cpp by mistake. llvm-svn: 267014
* [SimplifyCFG] Fold `llvm.guard(false)` to unreachableSanjoy Das2016-04-211-1/+19
| | | | | | | | | | | | | | Summary: `llvm.guard(false)` always bails out of the current compilation unit, so we can prune any control flow following it. Reviewers: hfinkel, pcc, reames Subscribers: majnemer, reames, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19245 llvm-svn: 266955
* 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
* [ValueTracking] Make isImpliedCondition return an Optional<bool>. NFC.Chad Rosier2016-04-201-10/+11
| | | | | | Phabricator Revision: http://reviews.llvm.org/D19277 llvm-svn: 266904
* [ThinLTO] Prevent importing of "llvm.used" valuesTeresa Johnson2016-04-202-17/+20
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch prevents importing from (and therefore exporting from) any module with a "llvm.used" local value. Local values need to be promoted and renamed when importing, and their presense on the llvm.used variable indicates that there are opaque uses that won't see the rename. One such example is a use in inline assembly. See also the discussion at: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098047.html As part of this, move collectUsedGlobalVariables out of Transforms/Utils and into IR/Module so that it can be used more widely. There are several other places in LLVM that used copies of this code that can be cleaned up as a follow on NFC patch. Reviewers: joker.eph Subscribers: pcc, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18986 llvm-svn: 266877
* ThinLTO: never promote as external weakMehdi Amini2016-04-201-1/+1
| | | | | | | | | This linkage is *not* intended to express that a declaration refers to a weak symbol, but that the symbol might not be present at link time. I don't believe it was the intent. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266856
* [ValueTracking] Improve isImpliedCondition for conditions with matching ↵Chad Rosier2016-04-191-2/+6
| | | | | | | | | | | | | | | operands. This patch improves SimplifyCFG to catch cases like: if (a < b) { if (a > b) <- known to be false unreachable; } Phabricator Revision: http://reviews.llvm.org/D18905 llvm-svn: 266767
* Correct IDF calculator for ReverseIDFDaniel Berlin2016-04-192-2/+2
| | | | | | | | | | | | | | Summary: Need to use predecessors for reverse graph, successors for forward graph. succ_iterator/pred_iterator are not compatible, this patch is all the work necessary to work around that (which is what everywhere else does). Not sure if there is a better way, so cc'ing some random folks to take a gander :) Reviewers: dblaikie, qcolombet, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18796 llvm-svn: 266718
* [NFC] Header cleanupMehdi Amini2016-04-185-7/+2
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* Transforms: Try harder to fix bootstrap after r266565Duncan P. N. Exon Smith2016-04-171-2/+2
| | | | | | | | | This catches two nullptr insertions into the ValueMap I missed in r266567. I missed CloneFunction becuase it never calls RemapInstruction directly. Here's one of the still-failing bots: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11496 llvm-svn: 266570
* 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
* Transforms: Fix bootstrap after r266565Duncan P. N. Exon Smith2016-04-171-4/+4
| | | | | | | | | | | | Apparently there isn't test coverage for all of these. I'd appreciate if someone with could reproduce and send me something to reduce, but for now I've just looked for users of RemapInstruction and MapValue and ensured they don't accidentally insert nullptr. Here is one of the bootstraps that caught: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11494 llvm-svn: 266567
* ValueMapper: Don't allow explicit null mappings of Values, NFCDuncan P. N. Exon Smith2016-04-172-3/+5
| | | | | | | | | 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
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-42/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [SimplifyCFG] propagate branch metadata when creating select (PR27344)Sanjay Patel2016-04-151-2/+2
| | | | | | | | | | This is almost identical to: http://reviews.llvm.org/rL264527 This doesn't solve PR27344; it just allows the profile weights to survive. To solve the bug, we need to use the profile weights in the backend. llvm-svn: 266442
* Fix null pointer access for discriminator assignment.Dehao Chen2016-04-141-0/+2
| | | | | | | | | | | | Summary: This fixes the buildbot failure. Reviewers: dnovillo, davidxl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19129 llvm-svn: 266360
* Update discriminator assignment algorithm to handle nested call correctly.Dehao Chen2016-04-141-20/+14
| | | | | | | | | | | | Summary: Add discriminator for nested call correctly. Reviewers: davidxl, dnovillo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19127 llvm-svn: 266354
* [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
* Simplify strlen to a subtraction for certain cases.David L Kreitzer2016-04-131-0/+51
| | | | | | | | Patch by Li Huang (li1.huang@intel.com) Differential Revision: http://reviews.llvm.org/D18230 llvm-svn: 266200
* Fix mismatch on returned type between header and implementation for ↵Mehdi Amini2016-04-121-1/+1
| | | | | | | createNameAnonFunctionPass() From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266151
* Add a pass to name anonymous/nameless functionMehdi Amini2016-04-123-0/+104
| | | | | | | | | | | | | | | | Summary: For correct handling of alias to nameless function, we need to be able to refer them through a GUID in the summary. Here we name them using a hash of the non-private global names in the module. Reviewers: tejohnson Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18883 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266132
* ThinLTO renaming: use module hash instead of position in the summaryMehdi Amini2016-04-111-1/+1
| | | | | | | | | This is more robust to changes in the link ordering. Differential Revision: http://reviews.llvm.org/D18946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266018
* Fix a couple of redundant conditional expressions (PR27283, PR28282)Hans Wennborg2016-04-111-1/+1
| | | | llvm-svn: 265987
* [LoopUtils, LV] Fix PR27246 (first-order recurrences)Matthew Simpson2016-04-111-1/+1
| | | | | | | | | | | | This patch ensures that when we detect first-order recurrences, we reject a phi node if its previous value is also a phi node. During vectorization the initial and previous values of the recurrence are shuffled together to create the value for the current iteration. However, phi nodes are not widened like other instructions. This fixes PR27246. Differential Revision: http://reviews.llvm.org/D18971 llvm-svn: 265983
* This reverts commit r265913 and r265912Sanjoy Das2016-04-111-107/+0
| | | | | | | | | See PR27315 r265913: "[IndVars] Eliminate op.with.overflow when possible" r265912: "[SCEV] See through op.with.overflow intrinsics" llvm-svn: 265950
* [IndVars] Eliminate op.with.overflow when possibleSanjoy Das2016-04-101-0/+107
| | | | | | | | | | | | | | | Summary: If we can prove that an op.with.overflow intrinsic does not overflow, we can get rid of the intrinsic, and replace it with non-wrapping arithmetic. Reviewers: atrick, regehr Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18685 llvm-svn: 265913
* Maintain calling convention when inling calls to llvm.deoptimizeSanjoy Das2016-04-091-1/+3
| | | | | | | The behavior here was buggy -- we'd forget the calling convention after inlining a callsite calling llvm.deoptimize. llvm-svn: 265867
* test commitEvgeny Stupachenko2016-04-081-2/+2
| | | | llvm-svn: 265840
* 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
OpenPOWER on IntegriCloud