summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/LoopAccessAnalysis.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* LoopVectorize: teach loop vectorizer to vectorize calls.Michael Zolotukhin2015-03-171-0/+7
| | | | | | | The tests would be committed in a commit for http://reviews.llvm.org/D8131 Review: http://reviews.llvm.org/D8095 llvm-svn: 232530
* [LoopAccesses] Add debug message to indicate the result of the analysisAdam Nemet2015-03-101-4/+7
| | | | | | | | | | The debug message was pretty confusing here. It only reported the situation with memchecks without the result of the dependence analysis. Now it prints whether the loop is safe from the POV of the dependence analysis and if yes, whether we need memchecks. llvm-svn: 231854
* LoopAccessAnalysis: Silence -Wreturn-type diagnostic from GCCDavid Majnemer2015-03-101-0/+3
| | | | llvm-svn: 231836
* [LAA-memchecks] Comment improvementAdam Nemet2015-03-101-2/+2
| | | | | | I forgot to roll this into r231816. It was requested by Hal in D8122. llvm-svn: 231821
* [LAA-memchecks 3/3] Introduce pointer partitions for memchecksAdam Nemet2015-03-101-10/+36
| | | | | | | | | | | | | | | | | This is the final patch that actually introduces the new parameter of partition mapping to RuntimePointerCheck::needsChecking. Another API (LAI::getInstructionsForAccess) is also exposed that helps to map pointers to instructions because ultimately we partition instructions. The WIP version of the Loop Distribution pass in D6930 has been adapted to use all this. See for example, how InstrPartitionContainer::computePartitionSetForPointers sets up the partitions using the above API and then calls to LAI::addRuntimeCheck with the pointer partitions. llvm-svn: 231818
* [LAA-memchecks 2/3] Move number of memcheck threshold checking to LVAdam Nemet2015-03-101-27/+3
| | | | | | | | | | | | | | | | | | | | | Now the analysis won't "fail" if the memchecks exceed the threshold. It is the transform pass' responsibility to perform the check. This allows the transform pass to further analyze/eliminate the memchecks. E.g. in Loop distribution we only need to check pointers that end up in different partitions. Note that there is a slight change of functionality here. The logic in analyzeLoop is that if dependence checking fails due to non-constant distance between the pointers, another attempt is made to prove safety of the dependences purely using run-time checks. Before this patch we could fail the loop due to exceeding the memcheck threshold after the first step, now we only check the threshold in the client after the full analysis. There is no measurable compile-time effect but I wanted to record this here. llvm-svn: 231817
* [LAA-memchecks 1/3] Split out NumComparisons checks. NFCAdam Nemet2015-03-101-22/+30
| | | | | | | | | | | | | | | The check for the number of memchecks will be moved to the client of this analysis. Besides allowing for transform-specific thresholds, this also lets Loop Distribution post-process the memchecks; Loop Distribution only needs memchecks between pointers of different partitions. The motivation for this first patch is to untangle the CanDoRT check from the NumComparison check before moving the NumComparison part. CanDoRT means that we couldn't determine the bounds for the pointer. Note that NumComparison is set independent of this flag. llvm-svn: 231816
* [LoopAccesses 3/3] Print the dependences with -analyzeAdam Nemet2015-03-101-1/+20
| | | | | | | | | | The dependences are now expose through the new getInterestingDependences API so we can use that with -analyze too and fix the FIXME. This lets us remove the test that relied on -debug to check the dependences. llvm-svn: 231807
* [LoopAccesses 2/3] Allow querying of interesting dependencesAdam Nemet2015-03-101-20/+100
| | | | | | | | | | | | | | | | | | | | | | | Gather an array of interesting dependences rather than just failing after the first unsafe one and regarding the loop unsafe. Loop Distribution needs to be able to collect all dependences in order to isolate the dependence cycles into their own partition. Since the dependence checking algorithm is quadratic in terms of accesses sharing the same underlying pointer, I am applying a cut-off threshold (MaxInterestingDependence). Exceeding that, the logic reverts back to the original approach deeming the loop unsafe upon encountering the first unsafe dependence. The main idea of the patch is to split isDepedent from directly answering the question whether the dep is safe for vectorization to return a dependence type which then gets mapped to old boolean result using Dependence::isSafeForVectorization. Tested that this was compile-time neutral on SpecINT2006 LTO bitcode inputs. No assembly change on the testsuite including external. llvm-svn: 231806
* [LoopAccesses 1/3] Expose MemoryDepChecker to LAA usersAdam Nemet2015-03-101-127/+8
| | | | | | | | | | | | LoopDistribution needs to query various results of the dependence analysis. This series will expose some more APIs and state of the dependence checker. This patch is a simple one to just expose the DepChecker instance. The set is compile-time neutral measured with LTO bitcode files of SpecINT2006. Also there is no assembly change on the testsuite. llvm-svn: 231805
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-25/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* [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
* [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
* [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
* 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
* [LV] Move addRuntimeCheck to LoopAccessAnalysisAdam Nemet2015-02-061-0/+106
| | | | | | | | | | | | | This will allow it to be shared with the new Loop Distribution pass. getFirstInst is currently duplicated across LoopVectorize.cpp and LoopAccessAnalysis.cpp. This is a short-term work-around until we figure out a better solution. NFC. (The code moved is adjusted a bit for the name of the Loop member and that PtrRtCheck is now a reference rather than a pointer.) llvm-svn: 228418
* [LoopVectorize] Move LoopAccessAnalysis to its own moduleAdam Nemet2015-02-011-0/+1084
Other than moving code and adding the boilerplate for the new files, the code being moved is unchanged. There are a few global functions that are shared with the rest of the LoopVectorizer. I moved these to the new module as well (emitLoopAnalysis, stripIntegerCast, replaceSymbolicStrideSCEV) along with the Report class used by emitLoopAnalysis. There is probably room for further improvement in this area. I kept DEBUG_TYPE "loop-vectorize" because it's used as the PassName with emitOptimizationRemarkAnalysis. This will obviously have to change. NFC. This is part of the patchset that splits out the memory dependence logic from LoopVectorizationLegality into a new class LoopAccessAnalysis. LoopAccessAnalysis will be used by the new Loop Distribution pass. llvm-svn: 227756
OpenPOWER on IntegriCloud