summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[SimplifyCFG] Extend TryToSimplifyUncondBranchFromEmptyBlock for ↵Reid Kleckner2016-05-022-153/+59
| | | | | | | | | | | empty block including lifetime intrinsics" This reverts commit r268254. This change causes assertion failures while building Chromium. Reduced test case coming soon. llvm-svn: 268288
* [SimplifyCFG] Extend TryToSimplifyUncondBranchFromEmptyBlock for empty block ↵Hans Wennborg2016-05-022-59/+153
| | | | | | | | | | | | | | | | | | including lifetime intrinsics Make it possible that TryToSimplifyUncondBranchFromEmptyBlock merges empty basic block including lifetime intrinsics as well as phi nodes and unconditional branch into its successor or predecessor(s). If successor of empty block has single predecessor, all contents including lifetime intrinsics are sinked into the successor. Otherwise, they are hoisted into its predecessor(s) and then merged into the predecessor(s). Patch by Josh Yoon <josh.yoon@samsung.com>! Differential Revision: http://reviews.llvm.org/D19257 llvm-svn: 268254
* Mark guards on true as "trivially dead"Sanjoy Das2016-04-291-2/+6
| | | | | | | | | This moves some logic added to EarlyCSE in rL268120 into `llvm::isInstructionTriviallyDead`. Adds a test case for DCE to demonstrate that passes other than EarlyCSE can now pick up on the new information. llvm-svn: 268126
* [MemorySSA] Fix bugs in walker; refactor unittests a bit.George Burgess IV2016-04-291-8/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two somewhat related bugs in MemorySSA's caching walker. These bugs were found because D19695 brought up the problem that we'd have defs cached to themselves, which is incorrect. The bugs this fixes are: - We would sometimes skip the nearest clobber of a MemoryAccess, because we would query our cache for a given potential clobber before checking if the potential clobber is the clobber we're looking for. The cache entry for the potential clobber would point to the nearest clobber *of the potential clobber*, so if that was a cache hit, we'd ignore the potential clobber entirely. - There are times (sometimes in DFS, sometimes in the getClobbering... functions) where we would insert cache entries that say a def clobbers itself. There's a bit of common code between the fixes for the bugs, so they aren't split out into multiple commits. This patch also adds a few unit tests, and refactors existing tests a bit to reduce the duplication of setup code. llvm-svn: 268087
* Unify XDEBUG and EXPENSIVE_CHECKS (into the latter), and add an option to ↵Filipe Cabecinhas2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | the cmake build to enable them. Summary: Historically, we had a switch in the Makefiles for turning on "expensive checks". This has never been ported to the cmake build, but the (dead-ish) code is still around. This will also make it easier to turn it on in buildbots. Reviewers: chandlerc Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits Differential Revision: http://reviews.llvm.org/D19723 llvm-svn: 268050
* [Inliner] Preserve llvm.mem.parallel_loop_access metadataHal Finkel2016-04-281-0/+31
| | | | | | | | | | | | | | | | | | | | | | | When inlining a call site with llvm.mem.parallel_loop_access metadata, this metadata needs to be propagated to all cloned memory-accessing instructions. Otherwise, inlining parts of the loop body will invalidate the annotation. With this functionality, we now vectorize the following as expected: void Body(int *res, int *c, int *d, int *p, int i) { res[i] = (p[i] == 0) ? res[i] : res[i] + d[i]; } void Test(int *res, int *c, int *d, int *p, int n) { int i; #pragma clang loop vectorize(assume_safety) for (i = 0; i < 1600; i++) { Body(res, c, d, p, i); } } llvm-svn: 267949
* [SimplifyCFG] propagate branch metadata when creating selectSanjay Patel2016-04-271-2/+2
| | | | | | | | There's no existing test for this path, and I don't know how to expose it in a regression test, but I'm assuming there's some reason this path exists. llvm-svn: 267813
* [InferAttrs] Mark memset_pattern16 params nocapture.Ahmed Bougacha2016-04-271-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D19471 llvm-svn: 267760
* [TLI] Unify LibFunc attribute inference. NFCI.Ahmed Bougacha2016-04-271-110/+718
| | | | | | | | | | | | | Now the pass is just a tiny wrapper around the util. This lets us reuse the logic elsewhere (done here for BuildLibCalls) instead of duplicating it. The next step is to have something like getOrInsertLibFunc that also sets the attributes. Differential Revision: http://reviews.llvm.org/D19470 llvm-svn: 267759
* [TLI] Unify LibFunc signature checking. NFCI.Ahmed Bougacha2016-04-271-362/+17
| | | | | | | | | I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
* [ThinLTO] Refine fix to avoid renaming of uses in inline assembly.Teresa Johnson2016-04-271-8/+16
| | | | | | | | | | | | | | | | | Summary: Refine the workaround from r266877 that attempts to prevent renaming of locals in inline assembly, so that in addition to looking for a llvm.used local value, that there is at least one inline assembly call in the module. Otherwise, debug functions added to the llvm.used can block importing/exporting unnecessarily. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D19573 llvm-svn: 267717
* [Cloning] cloneLoopWithPreheader(): add assert to ensure no sub-loopsVaivaswatha Nagaraj2016-04-271-0/+2
| | | | | | | | | | | | | | Summary: cloneLoopWithPreheader() does not update LoopInfo for sub-loop of the original loop being cloned. Add assert to ensure no sub-loops for loop being cloned. Reviewers: anemet, ashutosh.nema, hfinkel Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D15922 llvm-svn: 267671
* The patch fixes PR27392.Evgeny Stupachenko2016-04-271-9/+10
| | | | | | | | | | | | | | | | | Summary: It is incorrect to compare TripCount (which is BECount + 1) with extraiters (or Count) to check if we should enter unrolled loop or not, because TripCount can potentially overflow (when BECount is max unsigned integer). While comparing BECount with (Count - 1) is overflow safe and therefore correct. Reviewer: hfinkel Differential Revision: http://reviews.llvm.org/D19256 From: Evgeny Stupachenko <evstupac@gmail.com> llvm-svn: 267662
* ThinLTO: do not promote GlobalVariable that have a specific section.Mehdi Amini2016-04-271-0/+5
| | | | | | | Differential Revision: http://reviews.llvm.org/D18298 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267646
* [SimplifyCFG] propagate branch metadata when creating selectSanjay Patel2016-04-261-1/+1
| | | | llvm-svn: 267624
* Revert "[SimplifyLibCalls] sprintf doesn't copy null bytes"David Majnemer2016-04-261-4/+3
| | | | | | | | | | The destination buffer that sprintf uses is restrict qualified, we do not need to worry about derived pointers referenced via format specifiers. This reverts commit r267580. llvm-svn: 267605
* [SimplifyLibCalls] sprintf doesn't copy null bytesDavid Majnemer2016-04-261-3/+4
| | | | | | | | | | sprintf doesn't read or copy the terminating null byte from it's string operands. sprintf will append it's own after processing all of the format specifiers. This fixes PR27526. llvm-svn: 267580
* [SimplifyCFG] Preserve !llvm.mem.parallel_loop_access when mergingHal Finkel2016-04-262-1/+3
| | | | | | | | When SimplifyCFG merges identical instructions from both sides of a diamond, it can preserve !llvm.mem.parallel_loop_access (as it does with most of the other metadata). There's no real data or control dependency change in this case. llvm-svn: 267515
* [ValueTracking] Improve isImpliedCondition when the dominating cond is false.Chad Rosier2016-04-251-3/+5
| | | | llvm-svn: 267430
* replace duplicated static functions for profile metadata access with ↵Sanjay Patel2016-04-231-27/+8
| | | | | | BranchInst member function; NFCI llvm-svn: 267295
* improve documentation comments; NFCSanjay Patel2016-04-232-135/+10
| | | | llvm-svn: 267292
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-3/+3
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* [LoopUtils] Extend findStringMetadataForLoop to return the value for metadataAdam Nemet2016-04-221-7/+18
| | | | | | | | | | | | | | | | E.g. for: !1 = {"llvm.distribute", i32 1} it now returns the MDOperand for 1. I will use this in LoopDistribution to check the value of the metadata. Note that the change is backward-compatible with its current use in LoopVersioningLICM. An Optional implicitly converts to a bool depending whether it contains a value or not. llvm-svn: 267190
* [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
OpenPOWER on IntegriCloud