summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* Reduce double set lookups.Benjamin Kramer2015-02-271-2/+1
| | | | llvm-svn: 230798
* Remove the Forward Control Flow Integrity pass and its dependencies.Eric Christopher2015-02-273-57/+0
| | | | | | | | | This work is currently being rethought along different lines and if this work is needed it can be resurrected out of svn. Remove it for now as no current work in ongoing on it and it's unused. Verified with the authors before removal. llvm-svn: 230780
* SCEVExpander incorrectly marks generated subtractions as nuw/nswSanjoy Das2015-02-261-3/+6
| | | | | | | | | | | | | | | It is not sound to mark the increment operation as `nuw` or `nsw` based on a proof off of the add recurrence if the increment operation we emit happens to be a `sub` instruction. I could not come up with a test case for this -- the cases where SCEVExpander decides to emit a `sub` instruction is quite small, and I cannot think of a way I'd be able to get SCEV to prove that the increment does not overflow in those cases. Differential Revision: http://reviews.llvm.org/D7899 llvm-svn: 230673
* [LV/LoopAccesses] Backward dependences are not safe just because theAdam Nemet2015-02-261-2/+2
| | | | | | | | | | | accesses are via different types Noticed this while generalizing the code for loop distribution. I confirmed with Arnold that this was indeed a bug and managed to create a testcase. llvm-svn: 230647
* [LoopAccesses] Add command-line option for RuntimeMemoryCheckThresholdAdam Nemet2015-02-261-10/+11
| | | | | | | | Also remove the somewhat misleading initializers from VectorizationFactor and VectorizationInterleave. They will get initialized with the default ctor since no cl::init is provided. llvm-svn: 230608
* MemDepPrinter: Fix some nits introduced in r228596Ramkumar Ramachandra2015-02-251-3/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D7644 llvm-svn: 230582
* Bugfix: SCEVExpander incorrectly marks increment operations as no-wrapSanjoy Das2015-02-251-2/+34
| | | | | | | | | | | | | | | | | | | | | (The change was landed in r230280 and caused the regression PR22674. This version contains a fix and a test-case for PR22674). When emitting the increment operation, SCEVExpander marks the operation as nuw or nsw based on the flags on the preincrement SCEV. This is incorrect because, for instance, it is possible that {-6,+,1} is <nuw> while {-6,+,1}+1 = {-5,+,1} is not. This change teaches SCEV to mark the increment as nuw/nsw only if it can explicitly prove that the increment operation won't overflow. Apart from the attached test case, another (more realistic) manifestation of the bug can be seen in Transforms/IndVarSimplify/pr20680.ll. Differential Revision: http://reviews.llvm.org/D7778 llvm-svn: 230533
* Fix really obscure bug in CannotBeNegativeZero() (PR22688)Sanjay Patel2015-02-251-1/+7
| | | | | | | | | | With a diabolically crafted test case, we could recurse through this code and return true instead of false. The larger engineering crime is the use of magic numbers. Added FIXME comments for those. llvm-svn: 230515
* Revert r230280: "Bugfix: SCEVExpander incorrectly marks increment operations ↵Hans Wennborg2015-02-241-31/+2
| | | | | | | | | | as no-wrap" This caused PR22674, failing this assert: Instructions.h:2281: llvm::Value* llvm::PHINode::getOperand(unsigned int) const: Assertion `i_nocapture < OperandTraits<PHINode>::operands(this) && "getOperand() out of range!"' failed. llvm-svn: 230341
* Fix bug 22641Sanjoy Das2015-02-241-17/+5
| | | | | | | | | | | | | | | The bug was a result of getPreStartForExtend interpreting nsw/nuw flags on an add recurrence more strongly than is legal. {S,+,X}<nsw> implies S+X is nsw only if the backedge of the loop is taken at least once. NOTE: I had accidentally committed an unrelated change with the commit message of this change in r230275 (r230275 was reverted in r230279). This is the correct change for this commit message. Differential Revision: http://reviews.llvm.org/D7808 llvm-svn: 230291
* [LoopAccesses] LAA::getInfo to use const reference for stride parameterAdam Nemet2015-02-241-25/+24
| | | | | | And other required const-correctness fixes to make this work. llvm-svn: 230289
* Bugfix: SCEVExpander incorrectly marks increment operations as no-wrapSanjoy Das2015-02-231-2/+31
| | | | | | | | | | | | | | | | | | | | | When emitting the increment operation, SCEVExpander marks the operation as nuw or nsw based on the flags on the preincrement SCEV. This is incorrect because, for instance, it is possible that {-6,+,1} is <nuw> while {-6,+,1}+1 = {-5,+,1} is not. This change teaches SCEV to mark the increment as nuw/nsw only if it can explicitly prove that the increment operation won't overflow. Apart from the attached test case, another (more realistic) manifestation of the bug can be seen in Transforms/IndVarSimplify/pr20680.ll. NOTE: this change was landed with an incorrect commit message in rL230275 and was reverted for that reason in rL230279. This commit message is the correct one. Differential Revision: http://reviews.llvm.org/D7778 llvm-svn: 230280
* Revert 230275.Sanjoy Das2015-02-231-31/+2
| | | | | | | | 230275 got committed with an incorrect commit message due to a mixup on my side. Will re-land in a few moments with the correct commit message. llvm-svn: 230279
* Fix bug 22641Sanjoy Das2015-02-231-2/+31
| | | | | | | | | | | The bug was a result of getPreStartForExtend interpreting nsw/nuw flags on an add recurrence more strongly than is legal. {S,+,X}<nsw> implies S+X is nsw only if the backedge of the loop is taken at least once. Differential Revision: http://reviews.llvm.org/D7808 llvm-svn: 230275
* Prevent hoisting fmul from THEN/ELSE to IF if there is fmsub/fmadd opportunity.Chad Rosier2015-02-231-0/+4
| | | | | | | | | | | This patch adds the isProfitableToHoist API. For AArch64, we want to prevent a fmul from being hoisted in cases where it is more profitable to form a fmsub/fmadd. Phabricator Review: http://reviews.llvm.org/D7299 Patch by Lawrence Hu <lawrence@codeaurora.org> llvm-svn: 230241
* InstSimplify: simplify 0 / X if nnan and nszMehdi Amini2015-02-231-14/+30
| | | | | From: Fiona Glaser <fglaser@apple.com> llvm-svn: 230238
* [LoopAccesses] Change LAA:getInfo to return a constant referenceAdam Nemet2015-02-191-3/+4
| | | | | | | | As expected, this required a few more const-correctness fixes. Based on Hal's feedback on D7684. llvm-svn: 229899
* [LoopAccesses] Add -analyze supportAdam Nemet2015-02-191-0/+51
| | | | | | | | | | | | | | | | The LoopInfo in combination with depth_first is used to enumerate the loops. Right now -analyze is not yet complete. It only prints the result of the analysis, the report and the run-time checks. Printing the unsafe depedences will require a bit more reshuffling which I'd like to do in a follow-on to this patchset. Unsafe dependences are currently checked via -debug-only=loop-accesses in the new test. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229898
* [LoopAccesses] Split out LoopAccessReport from VectorizerReportAdam Nemet2015-02-191-18/+18
| | | | | | | | | | | | The only difference between these two is that VectorizerReport adds a vectorizer-specific prefix to its messages. When LAA is used in the vectorizer context the prefix is added when we promote the LoopAccessReport into a VectorizerReport via one of the constructors. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229897
* [LoopAccesses] Add missing const to APIs in VectorizationReportAdam Nemet2015-02-191-2/+2
| | | | | | | | | | When I split out LoopAccessReport from this, I need to create some temps so constness becomes necessary. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229896
* [LoopAccesses] Add canAnalyzeLoopAdam Nemet2015-02-191-1/+51
| | | | | | | | | | | This allows the analysis to be attempted with any loop. This feature will be used with -analysis. (LV only requests the analysis on loops that have already satisfied these tests.) This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229895
* [LoopAccesses] Change debug messages from LV to LAAAdam Nemet2015-02-191-38/+39
| | | | | | | | | Also add pass name as an argument to VectorizationReport::emitAnalysis. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229894
* [LoopAccesses] Create the analysis passAdam Nemet2015-02-191-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a function pass that runs the analysis on demand. The analysis can be initiated by querying the loop access info via LAA::getInfo. It either returns the cached info or runs the analysis. Symbolic stride information continues to reside outside of this analysis pass. We may move it inside later but it's not a priority for me right now. The idea is that Loop Distribution won't support run-time stride checking at least initially. This means that when querying the analysis, symbolic stride information can be provided optionally. Whether stride information is used can invalidate the cache entry and rerun the analysis. Note that if the loop does not have any symbolic stride, the entry should be preserved across Loop Distribution and LV. Since currently the only user of the pass is LV, I just check that the symbolic stride information didn't change when using a cached result. On the LV side, LoopVectorizationLegality requests the info object corresponding to the loop from the analysis pass. A large chunk of the diff is due to LAI becoming a pointer from a reference. A test will be added as part of the -analyze patch. Also tested that with AVX, we generate identical assembly output for the testsuite (including the external testsuite) before and after. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229893
* [LoopAccesses] Cache the result of canVectorizeMemoryAdam Nemet2015-02-191-13/+20
| | | | | | | | | | | | LAA will be an on-demand analysis pass, so we need to cache the result of the analysis. canVectorizeMemory is renamed to analyzeLoop which computes the result. canVectorizeMemory becomes the query function for the cached result. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229892
* [LoopAccesses] Stash the report from the analysis rather than emitting itAdam Nemet2015-02-191-1/+2
| | | | | | | | | | | The transformation passes will query this and then emit them as part of their own report. The currently only user LV is modified to do just that. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229891
* [LoopAccesses] Make VectorizerParams global + fix for cyclic depAdam Nemet2015-02-191-16/+41
| | | | | | | | | | | | | | | | | As LAA is becoming a pass, we can no longer pass the params to its constructor. This changes the command line flags to have external storage. These can now be accessed both from LV and LAA. VectorizerParams is moved out of LoopAccessInfo in order to shorten the code to access it. This commits also has the fix (D7731) to the break dependence cycle between the analysis and vector libraries. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229890
* Revert "Reformat."Adam Nemet2015-02-191-44/+42
| | | | | | | | | | This reverts commit r229651. I'd like to ultimately revert r229650 but this reformat stands in the way. I'll reformat the affected files once the the loop-access pass is fully committed. llvm-svn: 229889
* Reformat.NAKAMURA Takumi2015-02-181-42/+44
| | | | llvm-svn: 229651
* Revert r229622: "[LoopAccesses] Make VectorizerParams global" and others. ↵NAKAMURA Takumi2015-02-181-254/+82
| | | | | | | | | | | | | | | | | | r229622 brought cyclic dependencies between Analysis and Vector. r229622: "[LoopAccesses] Make VectorizerParams global" r229623: "[LoopAccesses] Stash the report from the analysis rather than emitting it" r229624: "[LoopAccesses] Cache the result of canVectorizeMemory" r229626: "[LoopAccesses] Create the analysis pass" r229628: "[LoopAccesses] Change debug messages from LV to LAA" r229630: "[LoopAccesses] Add canAnalyzeLoop" r229631: "[LoopAccesses] Add missing const to APIs in VectorizationReport" r229632: "[LoopAccesses] Split out LoopAccessReport from VectorizerReport" r229633: "[LoopAccesses] Add -analyze support" r229634: "[LoopAccesses] Change LAA:getInfo to return a constant reference" r229638: "Analysis: fix buildbots" llvm-svn: 229650
* Address post commit review on r229600.Sanjoy Das2015-02-181-2/+2
| | | | llvm-svn: 229646
* Analysis: fix buildbotsSaleem Abdulrasool2015-02-181-1/+1
| | | | | | | This should fix the compilation failure on the MSVC buildbots which find a std::make_unique and llvm::make_unique via ADL, resulting in ambiguity. llvm-svn: 229638
* [LoopAccesses] Change LAA:getInfo to return a constant referenceAdam Nemet2015-02-181-3/+4
| | | | | | | | As expected, this required a few more const-correctness fixes. Based on Hal's feedback on D7684. llvm-svn: 229634
* [LoopAccesses] Add -analyze supportAdam Nemet2015-02-181-0/+51
| | | | | | | | | | | | | | | | The LoopInfo in combination with depth_first is used to enumerate the loops. Right now -analyze is not yet complete. It only prints the result of the analysis, the report and the run-time checks. Printing the unsafe depedences will require a bit more reshuffling which I'd like to do in a follow-on to this patchset. Unsafe dependences are currently checked via -debug-only=loop-accesses in the new test. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229633
* [LoopAccesses] Split out LoopAccessReport from VectorizerReportAdam Nemet2015-02-181-18/+18
| | | | | | | | | | | | The only difference between these two is that VectorizerReport adds a vectorizer-specific prefix to its messages. When LAA is used in the vectorizer context the prefix is added when we promote the LoopAccessReport into a VectorizerReport via one of the constructors. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229632
* [LoopAccesses] Add missing const to APIs in VectorizationReportAdam Nemet2015-02-181-2/+2
| | | | | | | | | | When I split out LoopAccessReport from this, I need to create some temps so constness becomes necessary. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229631
* [LoopAccesses] Add canAnalyzeLoopAdam Nemet2015-02-181-1/+51
| | | | | | | | | | | This allows the analysis to be attempted with any loop. This feature will be used with -analysis. (LV only requests the analysis on loops that have already satisfied these tests.) This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229630
* [LoopAccesses] Factor out RuntimePointerCheck::needsCheckingAdam Nemet2015-02-181-9/+18
| | | | | | | | | Will be used by the new RuntimePointerCheck::print. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229629
* [LoopAccesses] Change debug messages from LV to LAAAdam Nemet2015-02-181-38/+39
| | | | | | | | | Also add pass name as an argument to VectorizationReport::emitAnalysis. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229628
* [LoopAccesses] Create the analysis passAdam Nemet2015-02-181-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a function pass that runs the analysis on demand. The analysis can be initiated by querying the loop access info via LAA::getInfo. It either returns the cached info or runs the analysis. Symbolic stride information continues to reside outside of this analysis pass. We may move it inside later but it's not a priority for me right now. The idea is that Loop Distribution won't support run-time stride checking at least initially. This means that when querying the analysis, symbolic stride information can be provided optionally. Whether stride information is used can invalidate the cache entry and rerun the analysis. Note that if the loop does not have any symbolic stride, the entry should be preserved across Loop Distribution and LV. Since currently the only user of the pass is LV, I just check that the symbolic stride information didn't change when using a cached result. On the LV side, LoopVectorizationLegality requests the info object corresponding to the loop from the analysis pass. A large chunk of the diff is due to LAI becoming a pointer from a reference. A test will be added as part of the -analyze patch. Also tested that with AVX, we generate identical assembly output for the testsuite (including the external testsuite) before and after. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229626
* [LoopAccesses] Make blockNeedsPredication staticAdam Nemet2015-02-181-3/+4
| | | | | | | | | | | | | | | | blockNeedsPredication is in LoopAccess in order to share it with the vectorizer. It's a utility needed by LoopAccess not strictly provided by it but it's a good place to share it. This makes the function static so that it no longer required to create an LoopAccessInfo instance in order to access it from LV. This was actually causing problems because it would have required creating LAI much earlier that LV::canVectorizeMemory(). This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229625
* [LoopAccesses] Cache the result of canVectorizeMemoryAdam Nemet2015-02-181-13/+20
| | | | | | | | | | | | LAA will be an on-demand analysis pass, so we need to cache the result of the analysis. canVectorizeMemory is renamed to analyzeLoop which computes the result. canVectorizeMemory becomes the query function for the cached result. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229624
* [LoopAccesses] Stash the report from the analysis rather than emitting itAdam Nemet2015-02-181-1/+2
| | | | | | | | | | | The transformation passes will query this and then emit them as part of their own report. The currently only user LV is modified to do just that. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229623
* [LoopAccesses] Make VectorizerParams globalAdam Nemet2015-02-181-16/+16
| | | | | | | | | | | | | | As LAA is becoming a pass, we can no longer pass the params to its constructor. This changes the command line flags to have external storage. These can now be accessed both from LV and LAA. VectorizerParams is moved out of LoopAccessInfo in order to shorten the code to access it. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229622
* [LoopAccesses] Rename LoopAccessAnalysis to LoopAccessInfoAdam Nemet2015-02-181-15/+14
| | | | | | | | | LoopAccessAnalysis will be used as the name of the pass. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. llvm-svn: 229621
* Generalize getExtendAddRecStart to work with both sign and zeroSanjoy Das2015-02-181-143/+218
| | | | | | | | | | | extensions. This change also removes `DEBUG(dbgs() << "SCEV: untested prestart overflow check\n");` because that case has a unit test now. Differential Revision: http://reviews.llvm.org/D7645 llvm-svn: 229600
* Bugfix: SCEV incorrectly marks certain expressions as nswSanjoy Das2015-02-181-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I could not come up with a test case for this one; but I don't think `getPreStartForSignExtend` can assume `AR` is `nsw` -- there is one place in scalar evolution that calls `getSignExtendAddRecStart(AR, ...)` without proving that `AR` is `nsw` (line 1564) OperandExtendedAdd = getAddExpr(WideStart, getMulExpr(WideMaxBECount, getZeroExtendExpr(Step, WideTy))); if (SAdd == OperandExtendedAdd) { // If AR wraps around then // // abs(Step) * MaxBECount > unsigned-max(AR->getType()) // => SAdd != OperandExtendedAdd // // Thus (AR is not NW => SAdd != OperandExtendedAdd) <=> // (SAdd == OperandExtendedAdd => AR is NW) const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW); // Return the expression with the addrec on the outside. return getAddRecExpr(getSignExtendAddRecStart(AR, Ty, this), getZeroExtendExpr(Step, Ty), L, AR->getNoWrapFlags()); } Differential Revision: http://reviews.llvm.org/D7640 llvm-svn: 229594
* Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer2015-02-171-2/+1
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
* Revert 229175Philip Reames2015-02-151-3/+1
| | | | | | This change is a logical suspect in 22587 and 22590. Given it's of minimal importanance and I can't get clang to build on my home machine, I'm reverting so that I can deal with this next week. llvm-svn: 229322
* Unify the two EH personality classification routines I wroteReid Kleckner2015-02-141-2/+2
| | | | | | We only need one. llvm-svn: 229193
* Analysis: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-142-10/+6
| | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) llvm-svn: 229192
OpenPOWER on IntegriCloud