Remainder operations with constant divisor can be modeled as quasi-affine
expression. This patch adds support for detecting and modeling them. We also
add a test that ensures they are correctly code generated.
This patch was extracted from a larger patch contributed by Johannes Doerfert
in http://reviews.llvm.org/D5293
llvm-svn: 240518
This makes the test cases nonaffine even if Polly some days gains support for
the srem instruction, an instruction which is currently not modeled but which
can clearly be modeled statically. A call to a function without definition
will always remain non-affine, as there is just insufficient static information
for it to be modeled more precisely.
llvm-svn: 240458
LLVM's instcombine already translates power-of-two sdivs that are known to be
exact to fast ashr instructions. Hence, there is no need to add this logic
ourselves.
Pointed-out-by: Johannes Doerfert
llvm-svn: 239025
We now verify that memory access functions imported via JSON are indeed defined
for the full iteration domain. Before this change we accidentally imported
memory mappings such as i -> i / 127, which only defined a mapped for values of
i that are evenly divisible by 127, but which did not define any mapping for the
remaining values, with the result that isl just generated an access expression
that had undefined behavior for all the unmapped values.
In the incorrect test cases, we now either use floor(i/127) or we use p/127 and
provide the information that p is indeed a multiple of 127.
llvm-svn: 239024
isl marks known non-negative numerators in modulo (and soon also division)
operations. We now exploit this by generating unsigned operations. This is
beneficial as unsigned operations with power-of-two denominators will be
translated by isl to fast bitshift or bitwise and operations.
llvm-svn: 238577
While looking through the test cases I realized we did not have a CHECK line
for a duplicate memory access which we may want to eliminate later. To ensure
we do not have (or later introduce) unnecessary memory accesses, we now tighten
the test cases to look for such a pattern (and add the CHECK: line that shows
the redundant memory access).
llvm-svn: 238227
This ensures we pass all tests independently of how we set the options
-disable-polly-intra-scop-scalar-to-array and -polly-model-phi-nodes.
(At least if we enable both or disable both. Enabling them individually makes
little sense, as they will hopefully disappear soon anyhow).
llvm-svn: 238087
To reduce compile time and to allow more and better quality SCoPs in
the long run we introduced scalar dependences and PHI-modeling. This
patch will now allow us to generate code if one or both of those
options are set. While the principle of demoting scalars as well as
PHIs to memory in order to communicate their value stays the same,
this allows to delay the demotion till the very end (the actual code
generation). Consequently:
- We __almost__ do not modify the code if we do not generate code
for an optimized SCoP in the end. Thus, the early exit as well as
the unprofitable option will now actually preven us from
introducing regressions in case we will probably not get better
code.
- Polly can be used as a "pure" analyzer tool as long as the code
generator is set to none.
- The original SCoP is almost not touched when the optimized version
is placed next to it. Runtime regressions if the runtime checks
chooses the original are not to be expected and later
optimizations do not need to revert the demotion for that part.
- We will generate direct accesses to the demoted values, thus there
are no "trivial GEPs" that select the first element of a scalar we
demoted and treated as an array.
Differential Revision: http://reviews.llvm.org/D7513
llvm-svn: 238070
Being here, we extend the interface to return the element type and not a pointer
to the element type. We also provide a function to get the size (in bytes) of
the elements stored in this array.
We currently still store the element size as an innermost dimension in
ScopArrayInfo, which is somehow inconsistent and should be addressed in future
patches.
llvm-svn: 237779
Modified two test cases to adjust to the above change in renaming.
These two files were causing the buildbot failure in Polly, #30204 for example.
Details in http://reviews.llvm.org/D9483
This checkin goes with r237150 and r237151
llvm-svn: 237203
Besides class, function and file names, we also change the command line option
from -polly-codegen-isl to just -polly-codegen. The isl postfix is a leftover
from the times when we still had the CLooG based -polly-codegen. Today it is
just redundant and we drop it.
llvm-svn: 237099
In the lnt benchmark MultiSource/Benchmarks/MallocBench/gs/gs with
scalar and PHI modeling we detected the multidimensional accesses
with sizes variant in the SCoP. This will check the sizes for validity.
llvm-svn: 236395
This option is enabled since a long time and there does not seem to be a
situation in which we would not want to print alias scopes. Remove this option
to reduce the set of command-line option combinations that may expose bugs.
llvm-svn: 235861
I just learned that target triples prevent test cases to be run on other
architectures. Polly test cases are until now sufficiently target independent
to not require any target triples. Hence, we drop them.
llvm-svn: 235384
In Polly we used both the term 'scattering' and the term 'schedule' to describe
the execution order of a statement without actually distinguishing between them.
We now uniformly use the term 'schedule' for the execution order. This
corresponds to the terminology of isl.
History: CLooG introduced the term scattering as the generated code can be used
as a sequential execution order (schedule) or as a parallel dimension
enumerating different threads of execution (placement). In Polly and/or isl the
term placement was never used, but we uniformly refer to an execution order as a
schedule and only later introduce parallelism. When doing so we do not talk
about about specific placement dimensions.
llvm-svn: 235380
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
This will allow the ScopDetection to detect non-affine regions that
contain loops. All loops contained will be collected and are
accessible to later passes in order to adjust the access functions.
As the loops are non-affine and will not be part of the polyhedral
representation later, all accesses that are variant in these loops
have to be over approximated as non-affine accesses. They are
therefore handled the same way as other non-affine accesses.
Additionally, we do not count non-affine loops for the profitability
heuristic, thus a region with only a non-affine loop will only be
detected if the general detection of loop free regions is enabled.
Differential Revision: http://reviews.llvm.org/D8152
llvm-svn: 234711
This change ensures that we sign-extend integer types in case non-matching
operands are encountered when generating a multi-dimensional access offset.
This fixes http://llvm.org/PR23124
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 234122
As soon as one operand of the product is invalid, the entire product is invalid.
This happens for example if one of the operands is not loop-invariant.
This fixes http://llvm.org/PR23125
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com
llvm-svn: 234119
This allows us to delinerize code such as:
A[][n]
for (i
for (j
A[i][n-j-1] = ...
which would previously have been delinearize to an access A[i+1][-j-1].
To recover the correct access we apply the piecewise expression:
{ A[i][j] -> A[i-1][i+N]: i < 0; A[i][j] -> A[i][i]: i >= 0}
This approach generalizes to higher dimensions.
llvm-svn: 233566
This will strip the constant factor of a parameter befor we add it to
the SCoP. As a result the access functions are simplified, e.g., for
the attached test case.
llvm-svn: 233501
When creating parameters the SCEVexpander may introduce new induction variables,
that possibly create scalar dependences in the original scop, before we code
generate the scop. The resulting scalar dependences may then inhibit correct
code generation of the scop. To prevent this, we first version the code without
a run-time check and only then introduce new parameters and the run-time
condition. The if-condition that guards the original scop from being modified by
the SCEVexpander.
This change causes some test case changes as the run-time conditions are now
introduced in the split basic block rather than in the entry basic block.
This fixes http://llvm.org/PR22069
Test case reduced by: Karthik Senthil
llvm-svn: 233477
This options was earlier used for experiments with the vectorizer, but to my
knowledge is not really used anymore. If anybody needs this, we can always
reintroduce this feature.
llvm-svn: 232934
Replacing the old band_tree based code with code that is based on the new
schedule tree [1] interface makes applying complex schedule transformations a lot
more straightforward. We now do not need to reason about the meaning of flat
schedules, but can use a more straightforward tree structure. We do not yet
exploit this a lot in the current code, but hopefully we will be able to do so
soon.
This change also allows us to drop some code, as isl now provides some higher
level interfaces to apply loop transformations such as tiling.
This change causes some small test case changes as isl uses a slightly different
way to perform loop tiling, but no significant functional changes are intended.
[1] http://impact.gforge.inria.fr/impact2014/papers/impact2014-verdoolaege.pdf
llvm-svn: 232911
These test cases did not verify the CHECK lines at all. We add the FileCheck
and also fix some broken CHECK lines. Being here, we extend the checks to
cover the whole loop structure.
llvm-svn: 232710
The BB vectorizer is deprecated and there is no point in generating code for it
any more. This option was introduced when there was not yet any loop vectorizer
in sight. Now being matured, Polly should target the loop vectorizer.
llvm-svn: 232099
Tobias Grosser