summaryrefslogtreecommitdiffstats
path: root/polly/lib/Analysis/ScopDetection.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [polly] Update uses of DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-151-12/+12
| | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM Differential Revision: https://reviews.llvm.org/D44978 llvm-svn: 332352
* [ScopDetect] Reject loop with multiple exit blocks.Michael Kruse2018-04-251-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current statement domain derivation algorithm does not (always) consider that different exit blocks of a loop can have different conditions to be reached. From the code for (int i = n; ; i-=2) { if (i <= 0) goto even; if (i <= 1) goto odd; A[i] = i; } even: A[0] = 42; return; odd: A[1] = 21; return; Polly currently derives the following domains: Stmt_even_critedge Domain := [n] -> { Stmt_even_critedge[] }; Stmt_odd Domain := [n] -> { Stmt_odd[] : (1 + n) mod 2 = 0 and n > 0 }; while the domain for the odd case is correct, Stmt_even is assumed to be executed unconditionally, which is obviously wrong. While projecting out the loop dimension in `adjustDomainDimensions`, it does not consider that there are other exit condition that have matched before. I don't know a how to fix this without changing a lot of code. Therefore This patch rejects loops with multiple exist blocks to fix the miscompile of test-suite's uuencode. The odd condition is transformed by LLVM to %cmp1 = icmp eq i64 %indvars.iv, 1 such that the project_out in adjustDomainDimensions() indeed only matches for odd n (using this condition only, we'd have an infinite loop otherwise). The even condition manifests as %cmp = icmp slt i64 %indvars.iv, 3 Because buildDomainsWithBranchConstraints() does not consider other exit conditions, it has to assume that the induction variable will eventually be lower than 3 and taking this exit. IMHO we need to reuse the algorithm that determines the number of iterations (addLoopBoundsToHeaderDomain) to determine which exit condition applies first. It has to happen in buildDomainsWithBranchConstraints() because the result will need to propagate to successor BBs. Currently addLoopBoundsToHeaderDomain() just look for union of all backedge conditions (which means leaving not the loop here). The patch in llvm.org/PR35465 changes it to look for exit conditions instead. This is required because there might be other exit conditions that do not alternatively go back to the loop header. Differential Revision: https://reviews.llvm.org/D45649 llvm-svn: 330858
* Allow arbitrary function calls for debugging purposes.Michael Kruse2018-04-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the switch -polly-debug-func to define the name of a debug function. This function is ignored for any validity check. Its purpose is to allow to observe a value after transformation by a SCoP, and to follow which statements are executed in which order. For instance, consider the following code: static void dbg_printf(int sum, int i) { fprintf(stderr, "The value of sum is %d, i=%d\n", sum, i); fflush(stderr); } void func(int n) { int sum = 0; for (int i = 0; i < 16; i+=1) { sum += i; dbg_printf(sum, i); } } Executing this after Polly's codegen with -polly-debug-func=dbg_printf reveals the new execution order and the assumed values at that point of execution. Differential Revision: https://reviews.llvm.org/D45728 llvm-svn: 330466
* [ScopDetect / ScopInfo] Get statistics for scops without any loop correctlyTobias Grosser2018-04-181-2/+9
| | | | | | Make sure we also counts scops not containing any loops. llvm-svn: 330285
* Adjust to clang-format changesTobias Grosser2018-03-201-2/+0
| | | | llvm-svn: 328005
* Update to latest clang-format. [NFC]Siddharth Bhat2017-12-051-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D40791 llvm-svn: 319718
* Update format after clang-format change. NFC.Michael Kruse2017-11-301-3/+3
| | | | | | In r319314 clang-format changed its reflowing logic. llvm-svn: 319426
* Rename OptimizationDiagnosticInfo.h to OptimizationRemarkEmitter.hAdam Nemet2017-10-091-1/+1
| | | | | | Polly version of r315249 on LLVM trunk. llvm-svn: 315253
* [ScopDetect] Do not add loads out of the SCoP to required invariant loads.Michael Kruse2017-10-011-1/+1
| | | | | | | | | | | | | | | | Loads before the SCoP are always invariant within the SCoP and therefore are no "required invariant loads". An assertion failes in ScopBuilder when it finds such an invariant load. Fix by not adding such loads to the required invariant load list. This likely will cause the region to be not considered a valid SCoP. We may want to unconditionally accept instructions defined before the region as valid invariant conditions instead of rejecting them. This fixes a compilation crash of SPEC CPU2006 453.povray's render.cpp. llvm-svn: 314636
* [ScopInfo] Allow PHI nodes that reference an error blockTobias Grosser2017-09-261-2/+11
| | | | | | As long as these PHI nodes are only referenced by terminator instructions. llvm-svn: 314212
* [ScopInfo] Allow invariant loads in branch conditionsTobias Grosser2017-09-251-0/+6
| | | | | | | In case the value used in a branch condition is a load instruction, assume this load to be invariant. llvm-svn: 314146
* [ScopInfo] Allow uniform branch conditionsTobias Grosser2017-09-251-0/+7
| | | | | | | If all but one branch come from an error condition and the incoming value from this branch is a constant, we can model this branch. llvm-svn: 314116
* [ScopDetect/Info] Look through PHIs that follow an error blockTobias Grosser2017-09-241-0/+3
| | | | | | | | | | | In case a PHI node follows an error block we can assume that the incoming value can only come from the node that is not an error block. As a result, conditions that seemed non-affine before are now in fact affine. This is a recommit of r312663 after fixing test/Isl/CodeGen/phi_after_error_block_outside_of_scop.ll llvm-svn: 314075
* Revert "[ScopDetect/Info] Look through PHIs that follow an error block"Michael Kruse2017-09-061-3/+0
| | | | | | | | | | This reverts commit r312410 - [ScopDetect/Info] Look through PHIs that follow an error block The commit caused generation of invalid IR due to accessing a parameter that does not dominate the SCoP. llvm-svn: 312663
* [ScopDetect/Info] Look through PHIs that follow an error blockTobias Grosser2017-09-021-0/+3
| | | | | | | | In case a PHI node follows an error block we can assume that the incoming value can only come from the node that is not an error block. As a result, conditions that seemed non-affine before are now in fact affine. llvm-svn: 312410
* [Detect] Consider nested loop profitable if entry block is not in loopTobias Grosser2017-08-271-2/+7
| | | | | | | | | | | | | In cases where the entry block of a scop was not contained in a loop that was part of the scop region and at the same time there was a loop surrounding the scop, we missed to count the loops in the scop and consequently did not consider the scop profitable. We correct this by only moving to the loop parent, in case the current loop is loop contained in the scop. This increases the number of loops in COSMO which we assume to be profitable from 3974 to 4981. llvm-svn: 311863
* [Polly] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-08-251-27/+68
| | | | | | other minor fixes (NFC). llvm-svn: 311802
* Revert "[polly] Fix ScopDetectionDiagnostic test failure caused by r310940"Tobias Grosser2017-08-241-12/+39
| | | | | | | | This reverts commit 950849ece9bb8fdd2b41e3ec348b9653b4e37df6. This commit broke various buildbots. llvm-svn: 311692
* [ScopDetect] Include zero-iteration loops in loop count.Michael Kruse2017-08-231-18/+5
| | | | | | | | | | | | | | | | | | | | Loop with zero iteration are, syntactically, loops. They have been excluded from the loop counter even for the non-profitable counters. This seems to be unintentially as the sentinel value of '0' minimal iterations does exclude such loops. Fix by never considering the iteration count when the sentinel value of 0 is found. This makes the recently added NumTotalLoops couter redundant with NumLoopsOverall, which now is equivalent. Hence, NumTotalLoops is removed as well. Note: The test case 'ScopDetect/statistics.ll' effectively does not check profitability, because -polly-process-unprofitable is passed to all test cases. llvm-svn: 311551
* [polly] Fix ScopDetectionDiagnostic test failure caused by r310940Jakub Kuderski2017-08-221-39/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: ScopDetection used to check if a loop withing a region was infinite and emitted a diagnostic in such cases. After r310940 there's no point checking against that situation, as infinite loops don't appear in regions anymore. The test failure was observed on these two polly buildbots: http://lab.llvm.org:8011/builders/polly-arm-linux/builds/8368 http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/10310 This patch XFAILs `ReportLoopHasNoExit.ll` and turns infinite loop detection into an assert. Reviewers: grosser, sanjoy, bollu Reviewed By: grosser Subscribers: efriedma, aemerson, kristof.beyls, dberlin, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D36776 llvm-svn: 311503
* [ScopDetection] Add stat for total number of loops.Michael Kruse2017-08-221-0/+14
| | | | | | | The total number of loops is useful as a baseline comparing how many loops have been optimized in different configurations. llvm-svn: 311469
* [ScopInliner] Add a simple Scop-based inliner to polly.Siddharth Bhat2017-08-171-7/+8
| | | | | | | | | | | | | We add a ScopInliner pass which inlines functions based on a simple heuristic: Let `g` call `f`. If we can model all of `f` as a Scop, we inline `f` into `g`. This requires `-polly-detect-full-function` to be enabled. So, the pass asserts that `-polly-detect-full-function` is enabled. Differential Revision: https://reviews.llvm.org/D36832 llvm-svn: 311126
* [PM] Make the new-pm passes behave more like the legacy passesPhilip Pfaffe2017-08-041-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: Testing the new-pm passes becomes much easier once they behave more like the old passes in terms of the order in which Scops are processed and printed. This requires three changes: - ScopInfo: Use an ordered map to store scops - ScopInfo: Iterate and print Scops in reverse order to match legacy PM behaviour - ScopDetection: print function name in ScopAnalysisPrinter Reviewers: grosser, Meinersbur, bollu Reviewed By: grosser Subscribers: pollydev, llvm-commits Differential Revision: https://reviews.llvm.org/D36303 llvm-svn: 310052
* [SD] Set PollyUseRuntimeAliasChecks correctlyPhilip Pfaffe2017-08-021-0/+5
| | | | llvm-svn: 309805
* [ScopDetect] add `-polly-ignore-func` flag to ignore functions by name.Siddharth Bhat2017-07-281-6/+21
| | | | | | | | | | Ignore all functions whose name match a regex. Useful because creating a regex that does *not* match a string is somewhat hard. Example: https://stackoverflow.com/questions/1240275/how-to-negate-specific-word-in-regex llvm-svn: 309377
* [Polly] [NFC] [ScopDetection] Make `polly-only-func` perform regex scop name ↵Siddharth Bhat2017-07-241-6/+15
| | | | | | | | | | | | | | match. Summary: - We were using `.count` in `StringRef`, which matches substrings. - We may want to use this for equality as well. - Generalise this, so allow regexes as a parameter to `polly-only-func`. Differential Revision: https://reviews.llvm.org/D35728 llvm-svn: 308875
* [Polly] [OptDiag] Updating Polly Diagnostics RemarksEli Friedman2017-07-171-5/+9
| | | | | | | | | | | | | | | | | Utilizing newer LLVM diagnostic remark API in order to enable use of opt-viewer tool. Polly Diagnostic Remarks also now appear in YAML remark file. In this patch, I've added the OptimizationRemarkEmitter into certain classes where remarks are being emitted and update the remark emit calls itself. I also provide each remark a BasicBlock or Instruction from where it is being called, in order to compute the hotness of the remark. Patch by Tarun Rajendran! Differential Revision: https://reviews.llvm.org/D35399 llvm-svn: 308233
* [ScopDetection] If a loop is not part of a scop, none of it backedges can beTobias Grosser2017-07-151-3/+13
| | | | | | | | | | | | | | | | | | This patch makes sure that in case a loop is not fully contained within a region that later forms a SCoP, none of the loop backedges are allowed to be part of the region. We currently do not support the situation where only some of a loops backedges are part of a scop. Today, this can break both scop modeling and code generation. One such breaking test case is for example test/ScopDetectionDiagnostics/loop_partially_in_scop-2.ll, where we totally forgot to code generate some of the backedges. Fortunately, it is commonly not necessary to support these partial loops, it is way more common that either no backedge is included in a region or all loop backedge are included. This fixes a recent miscompile in MultiSource/Benchmarks/MiBench/consumer-typeset which was exposed after r306477. llvm-svn: 308113
* [Invariant Loads] Do not consider invariant loads to have dependences.Siddharth Bhat2017-07-131-1/+2
| | | | | | | | | | | | | | | | | We need to relax constraints on invariant loads so that they do not create fake RAW dependences. So, we do not consider invariant loads as scalar dependences in a region. During these changes, it turned out that we do not consider `llvm::Value` replacements correctly within `PPCGCodeGeneration` and `ISLNodeBuilder`. The replacements dictated by `ValueMap` were not being followed in all places. This was fixed in this commit. There is no clean way to decouple this change because this bug only seems to arise when the relaxed version of invariant load hoisting was enabled. Differential Revision: https://reviews.llvm.org/D35120 llvm-svn: 307907
* [Polly] [ScopDetection] Allow passing multiple functions to `-polly-only-func`.Siddharth Bhat2017-06-091-5/+13
| | | | | | | | - This is useful to run optimisations on only certain functions. Differential Revision: https://reviews.llvm.org/D33990 llvm-svn: 305060
* Fix a lot of typos. NFC.Michael Kruse2017-06-081-4/+4
| | | | llvm-svn: 304974
* Delinearize memory accesses that reference parameters coming from function callsTobias Grosser2017-05-271-5/+18
| | | | | | | | | | | | | | Certain affine memory accesses which we model today might contain products of parameters which we might combined into a new parameter to be able to create an affine expression that represents these memory accesses. Especially in the context of OpenCL, this approach looses information as memory accesses such as A[get_global_id(0) * N + get_global_id(1)] are assumed to be linear. We correctly recover their multi-dimensional structure by assuming that parameters that are the result of a function call at IR level likely are not parameters, but indeed induction variables. The resulting access is now A[get_global_id(0)][get_global_id(1)] for an array A[][N]. llvm-svn: 304075
* [Polly] Add handling of Top Level RegionsPhilip Pfaffe2017-05-241-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: My goal is to make the newly added `AllowWholeFunctions` options more usable/powerful. The changes to ScopBuilder.cpp are exclusively checks to prevent `Region.getExit()` from being dereferenced, since Top Level Regions (TLRs) don't have an exit block. In ScopDetection's `isValidCFG`, I removed a check that disallowed ReturnInstructions to have return values. This might of course have been intentional, so I would welcome your feedback on this and maybe a small explanation why return values are forbidden. Maybe it can be done but needs more changes elsewhere? The remaining changes in ScopDetection are simply to consider the AllowWholeFunctions option in more places, i.e. allow TLRs when it is set and once again avoid derefererncing `getExit()` if it doesn't exist. Finally, in ScopHelper.cpp I extended `polly::isErrorBlock` to handle regions without exit blocks as well: The original check was if a given BasicBlock dominates all predecessors of the exit block. Therefore I do the same for TLRs by regarding all BasicBlocks terminating with a ReturnInst as predecessors of a "virtual" function exit block. Patch by: Lukas Boehm Reviewers: philip.pfaffe, grosser, Meinersbur Reviewed By: grosser Subscribers: pollydev, llvm-commits, bollu Tags: #polly Differential Revision: https://reviews.llvm.org/D33411 llvm-svn: 303790
* [ScopDetection] Allow detection of full functionsTobias Grosser2017-05-191-2/+8
| | | | | | This is useful when only analyzing functions. llvm-svn: 303420
* [Polly][NewPM] Port ScopDetection to the new PassManagerPhilip Pfaffe2017-05-121-135/+162
| | | | | | | | | | | | | | | | Summary: This is a proof of concept of how to port polly-passes to the new PassManager architecture. This approach works ootb for Function-Passes, but might not be directly applicable to Scop/Region-Passes. While we could just run the Analyses/Transforms over functions instead, we'd surrender the nice pipelining behaviour we have now. Reviewers: Meinersbur, grosser Reviewed By: grosser Subscribers: pollydev, sanjoy, nemanjai, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D31459 llvm-svn: 302902
* [ScopDetection] Check for already known required-invariant loads [NFC]Tobias Grosser2017-05-041-0/+8
| | | | | | | | | | | For certain test cases we spent over 50% of the scop detection time in checking if a load is likely invariant. We can avoid most of these checks by testing early on if a load is expected to be invariant. Doing this reduces scop-detection time on a large benchmark from 52 seconds to just 25 seconds. No functional change is expected. llvm-svn: 302134
* Exploit BasicBlock::getModule to shorten codeTobias Grosser2017-04-111-2/+1
| | | | | Suggested-by: Roman Gareev <gareevroman@gmail.com> llvm-svn: 299914
* [ScopDetect/Info] Allow unconditional hoisting of loads from dereferenceable ↵Tobias Grosser2017-03-091-1/+10
| | | | | | | | | | | | ptrs In case LLVM pointers are annotated with !dereferencable attributes/metadata or LLVM can look at the allocation from which a pointer is derived, we can know that dereferencing pointers is safe and can be done unconditionally. We use this information to proof certain pointers as save to hoist and then hoist them unconditionally. llvm-svn: 297375
* [ScopDetection] Only allow SCoP-wide available base pointers.Michael Kruse2017-03-081-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify ScopDetection::isInvariant(). Essentially deny everything that is defined within the SCoP and is not load-hoisted. The previous understanding of "invariant" has a few holes: - Expressions without side-effects with only invariant arguments, but are defined withing the SCoP's region with the exception of selects and PHIs. These should be part of the index expression derived by ScalarEvolution and not of the base pointer. - Function calls with that are !mayHaveSideEffects() (typically functions with "readnone nounwind" attributes). An example is given below. @C = external global i32 declare float* @getNextBasePtr(float*) readnone nounwind ... %ptr = call float* @getNextBasePtr(float* %A, float %B) The call might return: * %A, so %ptr aliases with it in the SCoP * %B, so %ptr aliases with it in the SCoP * @C, so %ptr aliases with it in the SCoP * a new pointer everytime it is called, such as malloc() * a pointer into the allocated block of one of the aforementioned * any of the above, at random at each call Hence and contrast to a comment in the base_pointer.ll regression test, %ptr is not necessarily the same all the time. It might also alias with anything and no AliasAnalysis can tell otherwise if the definition is external. It is hence not suitable in the role of a base pointer. The practical problem with base pointers defined in SCoP statements is that it is not available globally in the SCoP. The statement instance must be executed first before the base pointer can be used. This is no problem if the base pointer is transferred as a scalar value between statements. Uses of MemoryAccess::setNewAccessRelation may add a use of the base pointer anywhere in the array. setNewAccessRelation is used by JSONImporter, DeLICM and D28518. Indeed, BlockGenerator currently assumes that base pointers are available globally and generates invalid code for new access relation (referring to the base pointer of the original code) if not, even if the base pointer would be available in the statement. This could be fixed with some added complexity and restrictions. The ExprBuilder must lookup the local BBMap and code that call setNewAccessRelation must check whether the base pointer is available first. The code would still be incorrect in the presence of aliasing. There is the switch -polly-ignore-aliasing to explicitly allow this, but it is hardly a justification for the additional complexity. It would still be mostly useless because in most cases either getNextBasePtr() has external linkage in which case the readnone nounwind attributes cannot be derived in the translation unit itself, or is defined in the same translation unit and gets inlined. Reviewed By: grosser Differential Revision: https://reviews.llvm.org/D30695 llvm-svn: 297281
* [ScopDetection] Require LoadInst base pointers to be hoisted.Michael Kruse2017-03-071-4/+13
| | | | | | | | | | | | | | | | | | Only when load-hoisted we can be sure the base pointer is invariant during the SCoP's execution. Most of the time it would be added to the required hoists for the alias checks anyway, except with -polly-ignore-aliasing, -polly-use-runtime-alias-checks=0 or if AliasAnalysis is already sure it doesn't alias with anything (for instance if there is no other pointer to alias with). Two more parts in Polly assume that this load-hoisting took place: - setNewAccessRelation() which contains an assert which tests this. - BlockGenerator which would use to the base ptr from the original code if not load-hoisted (if the access expression is regenerated) Differential Revision: https://reviews.llvm.org/D30694 llvm-svn: 297195
* [ScopDetection] Do not detect scops that exit to an unreachableTobias Grosser2017-03-071-1/+7
| | | | | | | | | | | | | | | Scops that exit with an unreachable are today still permitted, but make little sense to optimize. We therefore can already skip them during scop detection. This speeds up scop detection in certain cases and also ensures that bugpoint does not introduce unreachables when reducing test cases. In practice this change should have little impact, as the performance of unreachable code is unlikely to matter. This commit is part of a series that makes Polly more robust in the presence of unreachables. llvm-svn: 297151
* [ScopDetection] Do not allow required-invariant loads in non-affine regionTobias Grosser2017-03-021-1/+7
| | | | | | | | | | These loads cannot be savely hoisted as the condition guarding the non-affine region cannot be duplicated to also protect the hoisted load later on. Today they are dropped in ScopInfo. By checking for this early, we do not even try to model them and possibly can still optimize smaller regions not containing this specific required-invariant load. llvm-svn: 296744
* Remove all references to PostDominators. NFC.Michael Kruse2017-02-231-1/+0
| | | | | | | | | Marking a pass as preserved is necessary if any Polly pass uses it, even if it is not preserved within the generated code. Not marking it would cause the the Polly pass chain to be interrupted. It is not used by any Polly pass anymore, hence we can remove all references to it. llvm-svn: 295983
* [ScopInfo] Add statistics to count loops after scop modelingTobias Grosser2017-02-171-9/+10
| | | | llvm-svn: 295431
* [ScopDetection] Compute the maximal loop depth correctlyTobias Grosser2017-02-171-1/+1
| | | | | | | Before this change, we obtained loop depth numbers that were deeper then the actual loop depth. llvm-svn: 295430
* [ScopDetection] Add statistics to count the maximal number of scops in loopTobias Grosser2017-02-121-0/+7
| | | | llvm-svn: 294893
* Adjust formatting to commit r292110 [NFC]Tobias Grosser2017-01-161-2/+3
| | | | llvm-svn: 292123
* Allow to disable unsigned operations (zext, icmp ugt, ...)Johannes Doerfert2016-12-021-0/+12
| | | | | | | Unsigned operations are often useful to support but the heuristics are not yet tuned. This options allows to disable them if necessary. llvm-svn: 288521
* Do not allow multiple possibly aliasing ptrs in an expressionJohannes Doerfert2016-12-021-0/+47
| | | | | | | | | | | | Relational comparisons should not involve multiple potentially aliasing pointers. Similarly this should hold for switch conditions and the two conditions involved in equality comparisons (separately!). This is a heuristic based on the C semantics that does only allow such operations when the base pointers do point into the same object. Since this makes aliasing likely we will bail out early instead of producing a probably failing runtime check. llvm-svn: 288516
* [ScopDetect] Expand statistics of the detected scopsTobias Grosser2016-11-261-25/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We now collect: Number of total loops Number of loops in scops Number of scops Number of scops with maximal loop depth 1 Number of scops with maximal loop depth 2 Number of scops with maximal loop depth 3 Number of scops with maximal loop depth 4 Number of scops with maximal loop depth 5 Number of scops with maximal loop depth 6 and larger Number of loops in scops (profitable scops only) Number of scops (profitable scops only) Number of scops with maximal loop depth 1 (profitable scops only) Number of scops with maximal loop depth 2 (profitable scops only) Number of scops with maximal loop depth 3 (profitable scops only) Number of scops with maximal loop depth 4 (profitable scops only) Number of scops with maximal loop depth 5 (profitable scops only) Number of scops with maximal loop depth 6 and larger (profitable scops only) These statistics are certainly completely accurate as we might drop scops when building up their polyhedral representation, but they should give a good indication of the number of scops we detect. llvm-svn: 287973
OpenPOWER on IntegriCloud