summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactor isPointerOffset (NFC).Evgeniy Stepanov2019-08-191-7/+7
| | | | | | | | | | | | | | | | Summary: Simplify the API using Optional<> and address comments in https://reviews.llvm.org/D66165 Reviewers: vitalybuka Subscribers: hiraditya, llvm-commits, ostannard, pcc Tags: #llvm Differential Revision: https://reviews.llvm.org/D66317 llvm-svn: 369300
* [MemorySSA] Rename uses when inserting memory uses.Alina Sbirlea2019-08-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When inserting uses from outside the MemorySSA creation, we don't normally need to rename uses, based on the assumption that there will be no inserted Phis (if Def existed that required a Phi, that Phi already exists). However, when dealing with unreachable blocks, MemorySSA will optimize away Phis whose incoming blocks are unreachable, and these Phis end up being re-added when inserting a Use. There are two potential solutions here: 1. Analyze the inserted Phis and clean them up if they are unneeded (current method for cleaning up trivial phis does not cover this) 2. Leave the Phi in place and rename uses, the same way as whe inserting defs. This patch use approach 2. Resolves first test in PR42940. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66033 llvm-svn: 369291
* [MemorySSA] Loop passes should mark MSSA preserved when available.Alina Sbirlea2019-08-175-6/+6
| | | | | | | | This patch applies only to the new pass manager. Currently, when MSSA Analysis is available, and pass to each loop pass, it will be preserved by that loop pass. Hence, mark the analysis preserved based on that condition, vs the current `EnableMSSALoopDependency`. This leaves the global flag to affect only the entry point in the loop pass manager (in FunctionToLoopPassAdaptor). llvm-svn: 369181
* Move isPointerOffset function to ValueTracking (NFC).Evgeniy Stepanov2019-08-151-86/+2
| | | | | | | | | | | | | | Summary: To be reused in MemTag sanitizer. Reviewers: pcc, vitalybuka, ostannard Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66165 llvm-svn: 369062
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-155-7/+7
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [SCEV] Rename getMaxBackedgeTakenCount to getConstantMaxBackedgeTakenCount [NFC]Philip Reames2019-08-143-5/+5
| | | | llvm-svn: 368930
* [RLEV] Rewrite loop exit values for multiple exit loops w/o overall loop ↵Philip Reames2019-08-141-4/+20
| | | | | | | | | | | | exit count We already supported rewriting loop exit values for multiple exit loops, but if any of the loop exits were not computable, we gave up on all loop exit values. This patch generalizes the existing code to handle individual computable loop exits where possible. As discussed in the review, this is a starting point for figuring out a better API. The code is a bit ugly, but getting it in lets us test as we go. Differential Revision: https://reviews.llvm.org/D65544 llvm-svn: 368898
* InferAddressSpaces: Move target intrinsic handling to TTIMatt Arsenault2019-08-141-23/+15
| | | | | | | | I'm planning on handling intrinsics that will benefit from checking the address space enums. Don't bother moving the address collection for now, since those won't need th enums. llvm-svn: 368895
* InferAddressSpaces: Remove unnecessary check for ConstantIntMatt Arsenault2019-08-141-2/+2
| | | | | | The IR is invalid if this isn't a constant since immarg was added. llvm-svn: 368893
* Ignore indirect branches from callbr.Bill Wendling2019-08-141-2/+4
| | | | | | | | | | | | | | | | | | Summary: We can't speculate around indirect branches: indirectbr and invoke. The callbr instruction needs to be included here. Reviewers: nickdesaulniers, manojgupta, chandlerc Reviewed By: chandlerc Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66200 llvm-svn: 368873
* Revert '[LICM] Make Loop ICM profile aware' and 'Fix pass dependency for LICM'David L. Jones2019-08-141-75/+18
| | | | | | | This reverts r368526 (git commit 7e71aa24bc0788690fea7f0d7eab400c6a784deb) This reverts r368542 (git commit cb5a90fd314a7914cf293797bb4fd7a6841052cf) llvm-svn: 368800
* Fix pass dependency for LICMWenlei He2019-08-111-6/+7
| | | | | | Expected to address buildbot failure http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16285 caused by D65060. llvm-svn: 368542
* [LICM] Make Loop ICM profile awareWenlei He2019-08-111-17/+73
| | | | | | | | | | | | | | | | | | | | | Summary: Hoisting/sinking instruction out of a loop isn't always beneficial. Hoisting an instruction from a cold block inside a loop body out of the loop could hurt performance. This change makes Loop ICM profile aware - it now checks block frequency to make sure hoisting/sinking anly moves instruction to colder block. Test Plan: ninja check Reviewers: asbirlea, sanjoy, reames, nikic, hfinkel, vsk Reviewed By: asbirlea Subscribers: fhahn, vsk, davidxl, xbolva00, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65060 llvm-svn: 368526
* [Reassociate] try harder to convert negative FP constants to positiveSanjay Patel2019-08-101-72/+116
| | | | | | | | | | | | | | | | | | | | | | This is an extension of a transform that tries to produce positive floating-point constants to improve canonicalization (and hopefully lead to more reassociation and CSE). The original patches were: D4904 D5363 (rL221721) But as the test diffs show, these were limited to basic patterns by walking from an instruction to its single user rather than recursively moving up the def-use sequence. No fast-math is required here because we're only rearranging implicit FP negations in intermediate ops. A motivating bug is: https://bugs.llvm.org/show_bug.cgi?id=32939 Differential Revision: https://reviews.llvm.org/D65954 llvm-svn: 368512
* [InstSimplify] Report "Changed" also when only deleting dead instructionsBjorn Pettersson2019-08-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Make sure that we report that changes has been made by InstSimplify also in situations when only trivially dead instructions has been removed. If for example a call is removed the call graph must be updated. Bug seem to have been introduced by llvm-svn r367173 (commit 02b9e45a7e4b81), since the code in question was rewritten in that commit. Reviewers: spatel, chandlerc, foad Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65973 llvm-svn: 368401
* [LICM] Support unary FNeg in LICMCameron McInally2019-08-081-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D65908 llvm-svn: 368350
* Add llvm.licm.disable metadataTim Corringham2019-08-081-0/+6
| | | | | | | | | | | | | | For some targets the LICM pass can result in sub-optimal code in some cases where it would be better not to run the pass, but it isn't always possible to suppress the transformations heuristically. Where the front-end has insight into such cases it is beneficial to attach loop metadata to disable the pass - this change adds the llvm.licm.disable metadata to enable that. Differential Revision: https://reviews.llvm.org/D64557 llvm-svn: 368296
* [EarlyCSE] Add support for unary FNeg to EarlyCSECameron McInally2019-08-071-6/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D65815 llvm-svn: 368171
* [StructurizeCFG] Enable -structurizecfg-relaxed-uniform-regions by defaultTim Renouf2019-08-061-1/+1
| | | | | | | | | | | D62198 introduced an option to relax the checks for hasOnlyUniformBranches. This commit turns the option on by default, for better code generation in some cases in AMDGPU. Differential Revision: https://reviews.llvm.org/D63198 Change-Id: I9cbff002a1e74d3b7eb96b4192dc8129936d537d llvm-svn: 368042
* [Loop Peeling] Introduce an option for profile based peeling disabling.Serguei Katkov2019-08-022-24/+32
| | | | | | | | | | | | | | | | | This patch adds an ability to disable profile based peeling causing the peeling of all iterations and as a result prohibits further unroll/peeling attempts on that loop. The motivation to get an ability to separate peeling usage in pipeline where in the first part we peel only separate iterations if needed and later in pipeline we apply the full peeling which will prohibit further peeling. Reviewers: reames, fhahn Reviewed By: reames Subscribers: hiraditya, zzheng, dmgreen, llvm-commits Differential Revision: https://reviews.llvm.org/D64983 llvm-svn: 367668
* [Loop Peeling] Do not close further unroll/peel if profile based peeling was ↵Serguei Katkov2019-08-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | not used. Current peeling cost model can decide to peel off not all iterations but only some of them to eliminate conditions on phi. At the same time if any peeling happens the door for further unroll/peel optimizations on that loop closes because the part of the code thinks that if peeling happened it is profile based peeling and all iterations are peeled off. To resolve this inconsistency the patch provides the flag which states whether the full peeling basing on profile is enabled or not and peeling cost model is able to modify this field like it does not PeelCount. In a separate patch I will introduce an option to allow/disallow peeling basing on profile. To avoid infinite loop peeling the patch tracks the total number of peeled iteration through llvm.loop.peeled.count loop metadata. Reviewers: reames, fhahn Reviewed By: reames Subscribers: hiraditya, zzheng, dmgreen, llvm-commits Differential Revision: https://reviews.llvm.org/D64972 llvm-svn: 367647
* [IR] Value: add replaceUsesWithIf() utilityRoman Lebedev2019-08-011-6/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: While there is always a `Value::replaceAllUsesWith()`, sometimes the replacement needs to be conditional. I have only cleaned a few cases where `replaceUsesWithIf()` could be used, to both add test coverage, and show that it is actually useful. Reviewers: jdoerfert, spatel, RKSimon, craig.topper Reviewed By: jdoerfert Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, aheejin, george.burgess.iv, asbirlea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65528 llvm-svn: 367548
* Fix a release-only build warning triggered by rL367485Philip Reames2019-08-011-0/+3
| | | | llvm-svn: 367499
* [IndVars, RLEV] Support rewriting exit values in loops without known exits ↵Philip Reames2019-07-311-9/+7
| | | | | | | | | | (prep work) This is a prepatory patch for future work on support exit value rewriting in loops with a mixture of computable and non-computable exit counts. The intention is to be "mostly NFC" - i.e. not enable any interesting new transforms - but in practice, there are some small output changes. The test differences are caused by cases wherewhere getSCEVAtScope can simplify a single entry phi without needing any knowledge of the loop. llvm-svn: 367485
* [IPSCCP] Move callsite check to the beginning of the loop.Florian Hahn2019-07-311-14/+40
| | | | | | | | | | | | | | | | | | | | | We have some code marks instructions with struct operands as overdefined, but if the instruction is a call to a function with tracked arguments, this breaks the assumption that the lattice values of all call sites are not overdefined and will be replaced by a constant. This also re-adds the assertion from D65222, with additionally skipping non-callsite uses. This patch should address the cases reported in which the assertion fired. Fixes PR42738. Reviewers: efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D65439 llvm-svn: 367430
* [DivRemPairs] Fixup DNDEBUG build - variable is only used in assertionRoman Lebedev2019-07-311-0/+1
| | | | llvm-svn: 367423
* [DivRemPairs] Recommit: Handling for expanded-form rem - recomposition (PR42673)Roman Lebedev2019-07-311-6/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair is unsupported by target, nothing performs the opposite fold. We can't do that in InstCombine or DAGCombine since neither of those has access to TTI. So it makes most sense to teach `-div-rem-pairs` about it. If we matched rem in expanded form, we know we will be able to place div-rem pair next to each other so we won't regress the situation. Also, we shouldn't decompose rem if we matched already-decomposed form. This is surprisingly straight-forward otherwise. The original patch was committed in rL367288 but was reverted in rL367289 because it exposed pre-existing RAUW issues in internal data structures of the pass; those now have been addressed in a previous patch. https://bugs.llvm.org/show_bug.cgi?id=42673 Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner Reviewed By: bogner Subscribers: bogner, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65298 llvm-svn: 367419
* [DivRemPairs] Avoid RAUW pitfalls (PR42823)Roman Lebedev2019-07-311-26/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `DivRemPairs` internally creates two maps: * {sign, divident, divisor} -> div instruction * {sign, divident, divisor} -> rem instruction Then it iterates over rem map, and looks if there is an entry in div map with the same key. Then depending on some internal logic it may RAUW rem instruction with something else. But if that rem instruction is an input to other div/rem, then it was used as a key in these maps, so the old value (used in key) is now dandling, because RAUW didn't update those maps. And we can't even RAUW map keys in general, there's `ValueMap`, but we don't have a single `Value` as key... The bug was discovered via D65298, and the test there exists. Now, i'm not sure how to expose this issue in trunk. The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`, but i guess this didn't miscompiled anything thus far? I really don't think this is benin without that patch. The fix is actually rather straight-forward - instead of trying to somehow shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new `ValueMap` with key being a struct of `Value`s, we can just have an intermediate data structure - a vector, each entry containing matching `Div, Rem` pair, and pre-filling it before doing any modifications. This way we won't need to query map after doing RAUW, so no bug is possible. Reviewers: spatel, bogner, RKSimon, craig.topper Reviewed By: spatel Subscribers: hiraditya, hans, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65451 llvm-svn: 367417
* Recommit "[GVN] Preserve loop related analysis/canonical forms."Florian Hahn2019-07-311-5/+20
| | | | | | | This fixes some pipeline tests. This reverts commit d0b6f42936bfb6d56d325c732ae79400c9c6016a. llvm-svn: 367401
* Revert [GVN] Preserve loop related analysis/canonical forms.Florian Hahn2019-07-301-20/+5
| | | | | | This reverts r367332 (git commit 2d7227ec3ac91f36fc32b1c21e72e2f1f5d030ad) llvm-svn: 367335
* [GVN] Preserve loop related analysis/canonical forms.Florian Hahn2019-07-301-5/+20
| | | | | | | | | | | | | | | | | | | | LoopInfo can be easily preserved by passing it to the functions that modify the CFG (SplitCriticalEdge and MergeBlockIntoPredecessor. SplitCriticalEdge also preserves LoopSimplify and LCSSA form when when passing in LoopInfo. The test case shows that we preserve LoopSimplify and LoopInfo. Adding addPreservedID(LCSSAID) did not preserve LCSSA for some reason. Also I am not sure if it is possible to preserve those in the new pass manager, as they aren't analysis passes. Reviewers: reames, hfinkel, davide, jdoerfert Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D65137 llvm-svn: 367332
* [LoopFusion] Extend use of OptimizationRemarkEmitterKit Barton2019-07-301-73/+107
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch extends the use of the OptimizationRemarkEmitter to provide information about loops that are not fused, and loops that are not eligible for fusion. In particular, it uses the OptimizationRemarkAnalysis to identify loops that are not eligible for fusion and the OptimizationRemarkMissed to identify loops that cannot be fused. It also reuses the statistics to provide the messages used in the OptimizationRemarks. This provides common message strings between the optimization remarks and the statistics. I would like feedback on this approach, in general. If people are OK with this, I will flesh out additional remarks in subsequent commits. Subscribers: hiraditya, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63844 llvm-svn: 367327
* Revert "[DivRemPairs] Handling for expanded-form rem - recomposition (PR42673)"Roman Lebedev2019-07-301-97/+13
| | | | | | | | | | | test-suite/MultiSource/Benchmarks/DOE-ProxyApps-C/miniGMG broke: Only PHI nodes may reference their own value! %sub33 = srem i32 %sub33, %ranks_in_i This reverts commit r367288. llvm-svn: 367289
* [DivRemPairs] Handling for expanded-form rem - recomposition (PR42673)Roman Lebedev2019-07-301-13/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair is unsupported by target, nothing performs the opposite fold. We can't do that in InstCombine or DAGCombine since neither of those has access to TTI. So it makes most sense to teach `-div-rem-pairs` about it. If we matched rem in expanded form, we know we will be able to place div-rem pair next to each other so we won't regress the situation. Also, we shouldn't decompose rem if we matched already-decomposed form. This is surprisingly straight-forward otherwise. https://bugs.llvm.org/show_bug.cgi?id=42673 Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner Reviewed By: bogner Subscribers: bogner, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65298 llvm-svn: 367288
* [InstSimplify] remove quadratic time looping (PR42771)Sanjay Patel2019-07-271-21/+17
| | | | | | | | | | | | | | | | | | | | The test case from: https://bugs.llvm.org/show_bug.cgi?id=42771 ...shows a ~30x slowdown caused by the awkward loop iteration (rL207302) that is seemingly done just to avoid invalidating the instruction iterator. We can instead delay instruction deletion until we reach the end of the block (or we could delay until we reach the end of all blocks). There's a test diff here for a degenerate case with llvm.assume that is not meaningful in itself, but serves to verify this change in logic. This change probably doesn't result in much overall compile-time improvement because we call '-instsimplify' as a standalone pass only once in the standard -O2 opt pipeline currently. Differential Revision: https://reviews.llvm.org/D65336 llvm-svn: 367173
* Revert [IPSCCP] Add assertion to surface cases where we zap returns with ↵Florian Hahn2019-07-261-15/+0
| | | | | | | | | | overdefined users. This reverts r366998 (git commit 5354c83ece00690b4dbfa47925f8f5a8f33f1d9e) This breaks a linux kernel build and we have reproducer to investigate. llvm-svn: 367160
* [JumpThreading] Stop searching predecessor when the current bb is in aWei Mi2019-07-261-1/+11
| | | | | | | | | | | | | | | | | | | unreachable loop. updatePredecessorProfileMetadata in jumpthreading tries to find the first dominating predecessor block for a PHI value by searching upwards the predecessor block chain. But jumpthreading may see some temporary IR state which contains unreachable bb not being cleaned up. If an unreachable loop happens to be on the predecessor block chain, keeping chasing the predecessor block will run into an infinite loop. The patch fixes it. Differential Revision: https://reviews.llvm.org/D65310 llvm-svn: 367154
* [Loop Utils] Move utilty addStringMetadataToLoop to LoopUtils.cpp. NFC.Serguei Katkov2019-07-261-31/+0
| | | | | | | | | | | Just move the utility function to LoopUtils.cpp to re-use it in loop peeling. Reviewers: reames, Ashutosh Reviewed By: reames Subscribers: hiraditya, asbirlea, llvm-commits Differential Revision: https://reviews.llvm.org/D65264 llvm-svn: 367085
* Allow prefetching from non-zero address spacesJF Bastien2019-07-251-2/+2
| | | | | | | | | | | | | | | Summary: This is useful for targets which have prefetch instructions for non-default address spaces. <rdar://problem/42662136> Subscribers: nemanjai, javed.absar, hiraditya, kbarton, jkorous, dexonsmith, cfe-commits, llvm-commits, RKSimon, hfinkel, t.p.northover, craig.topper, anemet Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65254 llvm-svn: 367032
* [IPSCCP] Add assertion to surface cases where we zap returns with ↵Florian Hahn2019-07-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | overdefined users. We should only zap returns in functions, where all live users have a replace-able value (are not overdefined). Unused return values should be undefined. This should make it easier to detect bugs like in PR42738. Alternatively we could bail out of zapping the function returns, but I think it would be better to address those divergences between function and call-site values where they are actually caused. Reviewers: davide, efriedma Reviewed By: davide, efriedma Differential Revision: https://reviews.llvm.org/D65222 llvm-svn: 366998
* [PowerPC] exclude more icmps in LSR which is converted in later hardware ↵Chen Zheng2019-07-251-5/+6
| | | | | | | | loop pass Differential Revision: https://reviews.llvm.org/D64795 llvm-svn: 366976
* Let CorrelatedValuePropagation preserve LazyValueInfoDavid Bolvansky2019-07-241-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This patch makes CorrelatedValuePropagation preserve LazyValueInfo by adding LazyValueInfo::eraseValue & calling it whenever an instruction is erased. Passes `make check` , test-suite, and SPECrate 2017. Patch by aqjune (Juneyoung Lee) Reviewers: reames, mzolotukhin Reviewed By: reames Subscribers: xbolva00, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59349 llvm-svn: 366942
* [IndVars] Fix a subtle bug in optimizeLoopExitsPhilip Reames2019-07-231-2/+4
| | | | | | | | | | The original code failed to account for the fact that one exit can have a pointer exit count without all of them having pointer exit counts. This could cause two separate bugs: 1) We might exit the loop early, and leave optimizations undone. This is what triggered the assertion failure in the reported test case. 2) We might optimize one exit, then exit without indicating a change. This could result in an analysis invalidaton bug if no other transform is done by the rest of indvars. Note that the pointer exit counts are a really fragile concept. They show up only when we have a pointer IV w/o a datalayout to provide their size. It's really questionable to me whether the complexity implied is worth it. llvm-svn: 366829
* [IndVars] Speculative fix for an assertion failure seen in botsPhilip Reames2019-07-161-1/+6
| | | | | | I don't have an IR sample which is actually failing, but the issue described in the comment is theoretically possible, and should be guarded against even if there's a different root cause for the bot failures. llvm-svn: 366241
* [ADCE] Fix non-deterministic behaviour due to iterating over a pointer set.Amara Emerson2019-07-161-3/+8
| | | | | | | | Original patch by Yann Laigle-Chapuy Differential Revision: https://reviews.llvm.org/D64785 llvm-svn: 366215
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-163-3/+3
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [MemorySSA] Use SetVector to avoid nondeterminism.Alina Sbirlea2019-07-122-5/+5
| | | | | | | | | | | | | | | | Summary: Use a SetVector for DeadBlockSet. Resolves PR42574. Reviewers: george.burgess.iv, uabelho, dblaikie Subscribers: jlebar, Prazek, mgrang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64601 llvm-svn: 365970
* The variable "Latch" is only used in an assert, which makes builds that use ↵Sterling Augustine2019-07-121-2/+1
| | | | | | | | | | | | | | "-DNDEBUG" fail with unused variable messages. Summary: Move the logic into the assert itself. Subscribers: hiraditya, sanjoy, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64654 llvm-svn: 365943
* [IndVars] Use exit count reasoning to discharge obviously untaken exitsPhilip Reames2019-07-121-17/+110
| | | | | | | | | | Continue in the spirit of D63618, and use exit count reasoning to prove away loop exits which can not be taken since the backedge taken count of the loop as a whole is provably less than the minimal BE count required to take this particular loop exit. As demonstrated in the newly added tests, this triggers in a number of cases where IndVars was previously unable to discharge obviously redundant exit tests. And some not so obvious ones. Differential Revision: https://reviews.llvm.org/D63733 llvm-svn: 365920
* Delete dead storesFangrui Song2019-07-122-4/+2
| | | | llvm-svn: 365903
OpenPOWER on IntegriCloud