summaryrefslogtreecommitdiffstats
path: root/polly/test/ScopDetect/non-affine-loop-condition-dependent-access.ll
Commit message (Collapse)AuthorAgeFilesLines
* Allow invariant loads in the SCoP descriptionJohannes Doerfert2015-10-071-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
* Introduce -polly-process-unprofitableTobias Grosser2015-10-061-1/+1
| | | | | | | | | | This single option replaces -polly-detect-unprofitable and -polly-no-early-exit and is supposed to be the only option that disables compile-time heuristics that aim to bail out early on scops that are believed to not benefit from Polly optimizations. Suggested-by: Johannes Doerfert llvm-svn: 249426
* tests: Drop -polly-detect-unprofitable and -polly-no-early-exitTobias Grosser2015-10-061-3/+3
| | | | | | | | These flags are now always passed to all tests and need to be disabled if not needed. Disabling these flags, rather than passing them to almost all tests, significantly simplfies our RUN: lines. llvm-svn: 249422
* tests: Explicitly state if profitability tests should be usedTobias Grosser2015-10-061-1/+4
| | | | | | | | | | | | Polly's profitability heuristic saves compile time by skipping trivial scops or scops were we know no good optimization can be applied. For almost all our tests this heuristic makes little sense as we aim for minimal test cases when testing functionality. Hence, in almost all cases this heuristic is better be disabled. In preparation of disabling Polly's compile time heuristic by default in the test suite we first explicitly enable it in the couple of test cases that really use it (or run with/without heuristic side-by-side). llvm-svn: 249418
* [FIX] Count affine loops correctlyJohannes Doerfert2015-10-041-3/+5
| | | | | | | The "unprofitable" heuristic was broken and counted boxed loops even though we do not represent and optimize them. llvm-svn: 249274
* Allow loops in non-affine subregions -- SCoP ModelingJohannes Doerfert2015-04-121-0/+57
This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
OpenPOWER on IntegriCloud