summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [LSR] Allow giving priority to post-incrementing addressing modesKrzysztof Parzyszek2018-03-261-0/+14
| | | | | | | | | | | Implement TTI interface for targets to indicate that the LSR should give priority to post-incrementing addressing modes. Combination of patches by Sebastian Pop and Brendon Cahoon. Differential Revision: https://reviews.llvm.org/D44758 llvm-svn: 328490
* [PatternMatch] allow undef elements when matching vector FP +0.0Sanjay Patel2018-03-252-10/+11
| | | | | | | | | | | | | This continues the FP constant pattern matching improvements from: https://reviews.llvm.org/rL327627 https://reviews.llvm.org/rL327339 https://reviews.llvm.org/rL327307 Several integer constant matchers also have this ability. I'm separating matching of integer/pointer null from FP positive zero and renaming/commenting to make the functionality clearer. llvm-svn: 328461
* Revert r325687 (workaround for PR36032).Evgeny Stupachenko2018-03-221-7/+0
| | | | | | | | | | | | | | Summary: Revert r325687 workaround for PR36032 since a fix was committed in r326154. Reviewers: sbaranga Differential Revision: http://reviews.llvm.org/D44768 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 328257
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-211-1/+1
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* [InstSimplify] fp_binop X, NaN --> NaNSanjay Patel2018-03-211-10/+32
| | | | | | | | We propagate the existing NaN value when possible. Differential Revision: https://reviews.llvm.org/D44521 llvm-svn: 328140
* [MustExecute] Shwo the effect of using full loop info variantPhilip Reames2018-03-201-5/+7
| | | | | | | | Most basic possible test for the logic used by LICM. Also contains a speculative build fix for compiles which complain about a definition of a stuct K; followed by a declaration as class K; llvm-svn: 328058
* [MustExecute] Move isGuaranteedToExecute and related rourtines to AnalysisPhilip Reames2018-03-201-0/+135
| | | | | | Next step is to actually merge the implementations and get both implementations tested through the new printer. llvm-svn: 328055
* [MustExecute] Use the annotation style printerPhilip Reames2018-03-201-33/+54
| | | | | | | As suggested in the original review (https://reviews.llvm.org/D44524), use an annotation style printer instead. Note: The switch from -analyze to -disable-output in tests was driven by the fact that seems to be the idiomatic style used in annoation passes. I tried to keep both working, but the old style pass API for printers really doesn't make this easy. It invokes (runOnFunction, print(Module)) repeatedly. I decided the extra state wasn't worth it given the old pass manager is going away soonish anyway. llvm-svn: 328015
* Add an analysis printer for must execute reasoningPhilip Reames2018-03-203-0/+104
| | | | | | | | | | | | Many of our loop passes make use of so called "must execute" or "guaranteed to execute" facts to prove the legality of code motion. The basic notion is that we know (by assumption) an instruction didn't fault at it's original location, so if the location we move it to is strictly post dominated by the original, then we can't have introduced a new fault. At the moment, the testing for this logic is somewhat adhoc and done mostly through LICM. Since I'm working on that code, I want to improve the testing. This patch is the first step in that direction. It doesn't actually test the variant used by the loop passes - I need to move that to the Analysis library first - but instead exercises an alternate implementation used by SCEV. (I plan on merging both implementations.) Note: I'll be replacing the printing logic within this with an annotation based version in the near future. Anna suggested this in review, and it seems like a strictly better format. Differential Revision: https://reviews.llvm.org/D44524 llvm-svn: 328004
* [SCEV] Factor out isKnownViaInduction. NFC.Serguei Katkov2018-03-191-49/+38
| | | | | | | | | | | This just extracts the isKnownViaInduction from isKnownPredicate. Reviewers: sanjoy, mkazantsev, reames Reviewed By: mkazantsev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44554 llvm-svn: 327824
* [SCEV] Re-land: Fix isKnownPredicateSerguei Katkov2018-03-191-27/+73
| | | | | | | | | | | | | | | | | This is re-land of https://reviews.llvm.org/rL327362 with a fix and regression test. The crash was due to it is possible that for found MDL loop, LHS or RHS may contain an invariant unknown SCEV which does not dominate the MDL. Please see regression test for an example. Reviewers: sanjoy, mkazantsev, reames Reviewed By: mkazantsev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44553 llvm-svn: 327822
* [InstSimplify] loosen FMF for sqrt(X) * sqrt(X) --> XSanjay Patel2018-03-181-3/+6
| | | | | | | | | As shown in the code comment, we don't need all of 'fast', but we do need reassoc + nsz + nnan. Differential Revision: https://reviews.llvm.org/D43765 llvm-svn: 327796
* [GlobalsAA] Fix a pretty terrible bug that has been in GlobalsAA forChandler Carruth2018-03-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | a long time. The key thing is that we need to create value handles for every function that we create a `FunctionInfo` object around. Without this, when that function is deleted we can end up creating a new function that collides with its address and look up a stale AA result. With that AA result we can in turn miscompile code in ways that break. This is seriously one of the most absurd miscompiles I've seen. It only reproduced for us recently and only when building a very large server with both ThinLTO and PGO. A *HUGE* shout out to Wei Mi who tracked all of this down and came up with this patch. I'm just landing it because I happened to still by at a computer. He or I can work on crafting a test case to hit this (now that we know what to target) but it'll take a while, and we've been chasing this for a long time and need it fix Right Now. llvm-svn: 327761
* [NFC] Void variables used for asserts onlyMax Kazantsev2018-03-161-0/+2
| | | | llvm-svn: 327693
* [InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682)Roman Lebedev2018-03-151-0/+12
| | | | | | | | | | | | | | | | | | | This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
* [InstSimplify][NFC] simplifyICmpWithConstant(): refactor GetCompareTy() callsRoman Lebedev2018-03-151-4/+6
| | | | | | Preparation for D44425. llvm-svn: 327641
* [ConstantFolding, InstSimplify] Handle more vector GEPsMatthew Simpson2018-03-151-2/+2
| | | | | | | | | | This patch addresses some additional cases where the compiler crashes upon encountering vector GEPs. This should fix PR36116. Differential Revision: https://reviews.llvm.org/D44219 Reference: https://bugs.llvm.org/show_bug.cgi?id=36116 llvm-svn: 327638
* [PatternMatch, InstSimplify] allow undef elements when matching any vector ↵Sanjay Patel2018-03-151-8/+8
| | | | | | | | | | | FP zero This matcher implementation appears to be slightly more efficient than the generic constant check that it is replacing because every use was for matching FP patterns, but the previous code would check int and pointer type nulls too. llvm-svn: 327627
* [InstSimplify] remove 'nsz' requirement for frem 0, XSanjay Patel2018-03-151-5/+11
| | | | | | | | | | | From the LangRef definition for frem: "The value produced is the floating-point remainder of the two operands. This is the same output as a libm ‘fmod‘ function, but without any possibility of setting errno. The remainder has the same sign as the dividend. This instruction is assumed to execute in the default floating-point environment." llvm-svn: 327626
* [SCEV][NFC] Remove TBB, FBB parameters from exit limit computationsMax Kazantsev2018-03-151-38/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Methods `computeExitLimitFromCondCached` and `computeExitLimitFromCondImpl` take true and false branches as parameters and only use them for asserts and for identifying whether true/false branch belongs to the loop (which can be done once earlier). This fact complicates generalization of exit limit computation logic on guards because the guards don't have blocks to which they go in case of failure explicitly. The motivation of this patch is that currently this part of SCEV knows nothing about guards and only works with explicit branches. As result, it fails to prove that a loop for (i = 0; i < 100; i++) guard(i < 10); exits after 10th iteration, while in the equivalent example for (i = 0; i < 100; i++) if (i >= 10) break; SCEV easily proves this fact. We are going to change it in near future, and this is why we need to make these methods operate on more abstract level. This patch refactors this code to get rid of these parameters as meaningless and prepare ground for teaching these methods to work with guards as well as they work with explicit branching instructions. Differential Revision: https://reviews.llvm.org/D44419 llvm-svn: 327615
* [InstSimplify] fix folds for (0.0 - X) + X --> 0 (PR27151)Sanjay Patel2018-03-141-14/+10
| | | | | | | | | | | | | | | | As shown in: https://bugs.llvm.org/show_bug.cgi?id=27151 ...the existing fold could miscompile when X is NaN. The fold was also dependent on 'ninf' but that's not necessary. From IEEE-754 (with default rounding which we can assume for these opcodes): "When the sum of two operands with opposite signs (or the difference of two operands with like signs) is exactly zero, the sign of that sum (or difference) shall be +0...However, x + x = x − (−x) retains the same sign as x even when x is zero." llvm-svn: 327575
* [LazyValueInfo] PR33357 prevent infinite recursion on BinaryOperatorBrian M. Rzycki2018-03-131-3/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: It is possible for LVI to encounter instructions that are not in valid SSA form and reference themselves. One example is the following: %tmp4 = and i1 %tmp4, undef Before this patch LVI would recurse until running out of stack memory and crashed. This patch marks these self-referential instructions as Overdefined and aborts analysis on the instruction. Fixes https://bugs.llvm.org/show_bug.cgi?id=33357 Reviewers: craig.topper, anna, efriedma, dberlin, sebpop, kuhar Reviewed by: dberlin Subscribers: uabelho, spatel, a.elovikov, fhahn, eli.friedman, mzolotukhin, spop, evandro, davide, llvm-commits Differential Revision: https://reviews.llvm.org/D34135 llvm-svn: 327432
* [Evaluator] Evaluate load/store with bitcastEugene Leviant2018-03-131-34/+39
| | | | | | Differential revision: https://reviews.llvm.org/D43457 llvm-svn: 327381
* [SCEV][NFC] Smarter implementation of isAvailableAtLoopEntryMax Kazantsev2018-03-131-53/+1
| | | | | | | | | | isAvailableAtLoopEntry duplicates logic of `properlyDominates` after checking invariance. This patch replaces this logic with invocation of this method which is more profitable because it supports caching. Differential Revision: https://reviews.llvm.org/D43997 llvm-svn: 327373
* Revert [SCEV] Fix isKnownPredicateSerguei Katkov2018-03-131-67/+27
| | | | | | | | It is a revert of rL327362 which causes build bot failures with assert like Assertion `isAvailableAtLoopEntry(RHS, L) && "RHS is not available at Loop Entry"' failed. llvm-svn: 327363
* [SCEV] Fix isKnownPredicateSerguei Katkov2018-03-131-27/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IsKnownPredicate is updated to implement the following algorithm proposed by @sanjoy and @mkazantsev : isKnownPredicate(Pred, LHS, RHS) { Collect set S all loops on which either LHS or RHS depend. If S is non-empty a. Let PD be the element of S which is dominated by all other elements of S b. Let E(LHS) be value of LHS on entry of PD. To get E(LHS), we should just take LHS and replace all AddRecs that are attached to PD on with their entry values. Define E(RHS) in the same way. c. Let B(LHS) be value of L on backedge of PD. To get B(LHS), we should just take LHS and replace all AddRecs that are attached to PD on with their backedge values. Define B(RHS) in the same way. d. Note that E(LHS) and E(RHS) are automatically available on entry of PD, so we can assert on that. e. Return true if isLoopEntryGuardedByCond(Pred, E(LHS), E(RHS)) && isLoopBackedgeGuardedByCond(Pred, B(LHS), B(RHS)) Return true if Pred, L, R is known from ranges, splitting etc. } This is follow-up for https://reviews.llvm.org/D42417. Reviewers: sanjoy, mkazantsev, reames Reviewed By: sanjoy, mkazantsev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43507 llvm-svn: 327362
* [ThinLTO] Add funtions in callees metadata to CallGraphEdgesTaewook Oh2018-03-131-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If there's a callees metadata attached to the indirect call instruction, add CallGraphEdges to the callees mentioned in the metadata when computing FunctionSummary. * Why this is necessary: Consider following code example: ``` (foo.c) static int f1(int x) {...} static int f2(int x); static int (*fptr)(int) = f2; static int f2(int x) { if (x) fptr=f1; return f1(x); } int foo(int x) { (*fptr)(x); // !callees metadata of !{i32 (i32)* @f1, i32 (i32)* @f2} would be attached to this call. } (bar.c) int bar(int x) { return foo(x); } ``` At LTO time when `foo.o` is imported into `bar.o`, function `foo` might be inlined into `bar` and PGO-guided indirect call promotion will run after that. If the profile data tells that the promotion of `@f1` or `@f2` is beneficial, the optimizer will check if the "promoted" `@f1` or `@f2` (such as `@f1.llvm.0` or `@f2.llvm.0`) is available. Without this patch, importing `!callees` metadata would only add promoted declarations of `@f1` and `@f2` to the `bar.o`, but still the optimizer will assume that the function is available and perform the promotion. The result of that is link failure with `undefined reference to @f1.llvm.0`. This patch fixes this problem by adding callees in the `!callees` metadata to CallGraphEdges so that their definition would be properly imported into. One may ask that there already is a logic to add indirect call promotion targets to be added to CallGraphEdges. However, if profile data says "indirect call promotion is only beneficial under a certain inline context", the logic wouldn't work. In the code example above, if profile data is like ``` bar:1000000:100000 1:100000 1: foo:100000 1: 100000 f1:100000 ``` , Computing FunctionSummary for `foo.o` wouldn't add `foo->f1` to CallGraphEdges. (Also, it is at least "possible" that one can provide profile data to only link step but not to compilation step). Reviewers: tejohnson, mehdi_amini, pcc Reviewed By: tejohnson Subscribers: inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D44399 llvm-svn: 327358
* [MemorySSA] Fix comment + remove redundant dyn_casts; NFCGeorge Burgess IV2018-03-111-18/+12
| | | | | | StartingAccess is already a MemoryUseOrDef. llvm-svn: 327235
* [InstSimplify] fp_binop X, undef --> NaNSanjay Patel2018-03-101-14/+13
| | | | | | The variable operand could be NaN, so it's always safe to propagate NaN. llvm-svn: 327212
* [NFC] Consolidate six getPointerOperand() utility functions into one placeRenato Golin2018-03-093-40/+13
| | | | | | | | | | | | | | | | | There are six separate instances of getPointerOperand() utility. LoopVectorize.cpp has one of them, and I don't want to create a 7th one while I'm trying to move LoopVectorizationLegality into a separate file (eventual objective is to move it to Analysis tree). See http://lists.llvm.org/pipermail/llvm-dev/2018-February/120999.html for llvm-dev discussions Closes D43323. Patch by Hideki Saito <hideki.saito@intel.com>. llvm-svn: 327173
* [NFC] Factor out a helper function for checking if a block has a potential ↵Philip Reames2018-03-081-0/+9
| | | | | | early implicit exit. llvm-svn: 327065
* Expose must/may alias info in MemorySSA.Alina Sbirlea2018-03-081-35/+89
| | | | | | | | | | | | | | | | Summary: Building MemorySSA gathers alias information for Defs/Uses. Store and expose this information when optimizing uses (when building MemorySSA), and when optimizing defs or updating uses (getClobberingMemoryAccess). Current patch does not propagate alias information through MemoryPhis. Reviewers: gbiv, dberlin Subscribers: Prazek, sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D38569 llvm-svn: 327035
* DA: remove uses of GEP, only ask SCEVSebastian Pop2018-03-061-77/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's been quite some time the Dependence Analysis (DA) is broken, as it uses the GEP representation to "identify" multi-dimensional arrays. It even wrongly detects multi-dimensional arrays in single nested loops: from test/Analysis/DependenceAnalysis/Coupled.ll, example @couple6 ;; for (long int i = 0; i < 50; i++) { ;; A[i][3*i - 6] = i; ;; *B++ = A[i][i]; DA used to detect two subscripts, which makes no sense in the LLVM IR or in C/C++ semantics, as there are no guarantees as in Fortran of subscripts not overlapping into a next array dimension: maximum nesting levels = 1 SrcPtrSCEV = %A DstPtrSCEV = %A using GEPs subscript 0 src = {0,+,1}<nuw><nsw><%for.body> dst = {0,+,1}<nuw><nsw><%for.body> class = 1 loops = {1} subscript 1 src = {-6,+,3}<nsw><%for.body> dst = {0,+,1}<nuw><nsw><%for.body> class = 1 loops = {1} Separable = {} Coupled = {1} With the current patch, DA will correctly work on only one dimension: maximum nesting levels = 1 SrcSCEV = {(-2424 + %A)<nsw>,+,1212}<%for.body> DstSCEV = {%A,+,404}<%for.body> subscript 0 src = {(-2424 + %A)<nsw>,+,1212}<%for.body> dst = {%A,+,404}<%for.body> class = 1 loops = {1} Separable = {0} Coupled = {} This change removes all uses of GEP from DA, and we now only rely on the SCEV representation. The patch does not turn on -da-delinearize by default, and so the DA analysis will be more conservative in the case of multi-dimensional memory accesses in nested loops. I disabled some interchange tests, as the DA is not able to disambiguate the dependence anymore. To make DA stronger, we may need to compute a bound on the number of iterations based on the access functions and array dimensions. The patch cleans up all the CHECKs in test/Transforms/LoopInterchange/*.ll to avoid checking for snippets of LLVM IR: this form of checking is very hard to maintain. Instead, we now check for output of the pass that are more meaningful than dozens of lines of LLVM IR. Some tests now require -debug messages and thus only enabled with asserts. Patch written by Sebastian Pop and Aditya Kumar. Differential Revision: https://reviews.llvm.org/D35430 llvm-svn: 326837
* [ValueTracking] move helpers for SelectPatterns from InstCombine to ↵Sanjay Patel2018-03-061-0/+24
| | | | | | | | | ValueTracking Most of the folds based on SelectPatternResult belong in InstSimplify rather than InstCombine, so the helper code should be available to other passes/analysis. llvm-svn: 326812
* [InstSimplify] remove redundant foldsSanjay Patel2018-03-051-18/+0
| | | | | | | | | | | | The 'hasOneUse' check is a giveaway that something's not right. We never need to check that in InstSimplify because we don't create new instructions here. These are all handled as icmp simplifies which then trigger existing select simplifies, so there's no need to duplicate a composite fold of the two. llvm-svn: 326750
* Fix more spelling mistakes in comments of LLVM Analysis passesVedant Kumar2018-03-028-15/+15
| | | | | | | | Patch by Reshabh Sharma! Differential Revision: https://reviews.llvm.org/D43939 llvm-svn: 326601
* [PatternMatch, InstSimplify] fix m_NaN to work with vector constants and use itSanjay Patel2018-03-021-9/+6
| | | | | | | | | This is NFC for the moment (and independent of any potential NaN semantic controversy). Besides making the code in InstSimplify easier to read, the motivation is to eventually allow undef elements in vector constants to match too. A proposal to add the base logic for that is in D43792. llvm-svn: 326600
* [SCEV] Smart range calculation for SCEVUnknown PhisMax Kazantsev2018-03-011-0/+21
| | | | | | | | | | The range of SCEVUnknown Phi which merges values `X1, X2, ..., XN` can be evaluated as `U(Range(X1), Range(X2), ..., Range(XN))`. Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D43810 llvm-svn: 326418
* Fixed spelling mistake in comments of LLVM Analysis passesVedant Kumar2018-02-284-14/+14
| | | | | | | | Patch by Reshabh Sharma! Differential Revision: https://reviews.llvm.org/D43861 llvm-svn: 326352
* [Dominators] Remove verifyDomTree and add some verifying for Post Dom TreesDavid Green2018-02-281-0/+13
| | | | | | | | | | | | Removes verifyDomTree, using assert(verify()) everywhere instead, and changes verify a little to always run IsSameAsFreshTree first in order to print good output when we find errors. Also adds verifyAnalysis for PostDomTrees, which will allow checking of PostDomTrees it the same way we check DomTrees and MachineDomTrees. Differential Revision: https://reviews.llvm.org/D41298 llvm-svn: 326315
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to look through ↵Craig Topper2018-02-271-0/+6
| | | | | | | | | | ExtractElement. This is similar to what's done in computeKnownBits and computeSignBits. Don't do anything fancy just collect information valid for any element. Differential Revision: https://reviews.llvm.org/D43789 llvm-svn: 326237
* [MemorySSA] Call the correct dtorsGeorge Burgess IV2018-02-271-3/+2
| | | | | | | | | | | | It appears that there were many cases where we were directly (through templates) calling the dtor of MemoryAccess, which is conceptually an abstract class. This hasn't been a problem, since the data members of all of the subclasses of MemoryAccess have been POD. I'm planning on changing that. :) llvm-svn: 326175
* [SCEV] Cleanup SCEVInitRewriter. NFC.Serguei Katkov2018-02-271-2/+2
| | | | | | | | | | Set default value for IgnoreOtherLoops of SCEVInitRewriter::rewrite to true to be consistent with SCEVPostIncRewriter which does not have this parameter but behaves as it would be true. This is follow up for rL326067. llvm-svn: 326174
* Fix PR36032, PR35432Evgeny Stupachenko2018-02-271-0/+6
| | | | | | | | | | | | | | | Summary: The change fix an assert fail at ScalarEvolutionExpander.cpp: assert(ExitCount != SE.getCouldNotCompute() && "Invalid loop count"); Reviewers: sbaranga Differential Revision: http://reviews.llvm.org/D42604 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 326154
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to handle vector ↵Craig Topper2018-02-261-0/+18
| | | | | | | | | | | | | | | | constants. Summary: This allows vector fabs to be removed in more cases. Reviewers: spatel, arsenm, RKSimon Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43739 llvm-svn: 326138
* [SCEV] Factor out getUsedLoopsSerguei Katkov2018-02-261-4/+12
| | | | | | | | | | | | | | | The patch introduces the new function in ScalarEvolution to get all loops used in specified SCEV. This is a preparation for re-writing isKnownPredicate utility as described in https://reviews.llvm.org/D42417. Reviewers: sanjoy, mkazantsev, reames Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43504 llvm-svn: 326072
* [SCEV] Introduce SCEVPostIncRewriterSerguei Katkov2018-02-261-0/+41
| | | | | | | | | | | | | | | | The patch introduces the SCEVPostIncRewriter rewriter which is similar to SCEVInitRewriter but rewrites AddRec with post increment value of this AddRec. This is a preparation for re-writing isKnownPredicate utility as described in https://reviews.llvm.org/D42417. Reviewers: sanjoy, mkazantsev, reames Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43499 llvm-svn: 326071
* [SCEV] Extends the SCEVInitRewriterSerguei Katkov2018-02-261-8/+20
| | | | | | | | | | | | | | | | | The patch introduces an additional parameter IgnoreOtherLoops to SCEVInitRewriter. if it is equal to true then rewriter will not invalidate result in case SCEV depends on other loops then specified during creation. The patch does not change the default behavior. This is a preparation for re-writing isKnownPredicate utility as described in https://reviews.llvm.org/D42417. Reviewers: sanjoy, mkazantsev, reames Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43498 llvm-svn: 326067
* [MemorySSA] Remove a redundant dyn_cast.George Burgess IV2018-02-241-3/+2
| | | | | | StartingAccess is a MemoryUseOrDef. No need to check again. llvm-svn: 326000
* [MemorySSA] Fix a cache invalidation bug with removed accessesGeorge Burgess IV2018-02-231-1/+1
| | | | | | | I suspect there's a deeper issue here, but we probably shouldn't be using INVALID_MEMORYSSA_ID as liveOnEntry's ID anyway. llvm-svn: 325971
OpenPOWER on IntegriCloud