We use SplitEdge to split a conditional entry edge of the SCoP region.
However, SplitEdge can cause two different situations (depending on
whether or not the edge is critical). This patch tests
which one is present and deals with the former unhandled one.
It also refactors and unifies the case we have to change the basic
blocks of the SCoP to new ones (see replaceScopAndRegionEntry).
llvm-svn: 217802
During the IslAst parallelism check also compute the minimal dependency
distance and store it in the IstAst for node.
Reviewer: sebpop
Differential Revision: http://reviews.llvm.org/D4987
llvm-svn: 217729
Even though we previously correctly detected the multi-dimensional access
pattern for accesses with a certain base address, we only delinearized
non-affine accesses to this address. Affine accesses have not been touched and
remained as single dimensional accesses. The result was an inconsistent
description of accesses to the same array, with some being one dimensional and
some being multi-dimensional.
This patch ensures that all accesses are delinearized with the same
dimensionality as soon as a single one of them has been detected as non-affine.
While writing this patch, it became evident that the options
-polly-allow-nonaffine and -polly-detect-keep-going have not been properly
supported in case delinearization has been turned on. This patch adds relevant
test coverage and addresses these issues as well. We also added some more
documentation to the functions that are modified in this patch.
This fixes llvm.org/PR20123
Differential Revision: http://reviews.llvm.org/D5329
llvm-svn: 217728
At the moment we assume that only elements of identical size are stored/loaded
to a certain base pointer. This patch adds logic to the scop detection to verify
this.
Differential Revision: http://reviews.llvm.org/D5329
llvm-svn: 217727
We now verify that such functions are correctly detected even in combination
with delinearization. This change is added to ensure we have good test coverage
for the subsequent delinearization fix.
We also remove unnecessary instructions from the test case.
llvm-svn: 217664
This allows us to omit the GuardBB in front of created loops
if we can show the loop trip count is at least one. It also
simplifies the dominance relation inside the new created region.
A GuardBB (even with a constant branch condition) might trigger
false dominance errors during function verification.
Differential Revision: http://reviews.llvm.org/D5297
llvm-svn: 217525
Summary:
+ Refactor the runtime check (RTC) build function
+ Added helper function to create an PollyIRBuilder
+ Change the simplify region function to create not
only unique entry and exit edges but also enfore that
the entry edge is unconditional
+ Cleaned the IslCodeGeneration runOnScop function:
- less post-creation changes of the created IR
+ Adjusted and added test cases
Reviewers: grosser, sebpop, simbuerg, dpeixott
Subscribers: llvm-commits, #polly
Differential Revision: http://reviews.llvm.org/D5076
llvm-svn: 217508
The -e flag exits the script with a non-zero code if any subcommand
fails. This flag allows us to notice as early as possible if the
test was not properly regenerated using a command like:
$ create_ll.sh t.c && opt < t.ll -polly ...
The above pattern is useful when iteratively developing a test case
to guard against un-noticed syntax errors.
Differential Revision: http://reviews.llvm.org/D5276
llvm-svn: 217463
There was a bug in the IslAst which caused that no more outermost
parallel loops were detected/checked after a parallel outermost loop
of depth 1.
+ Test case attached
llvm-svn: 217452
In Polly we used to have a mix of test cases, some that used 'opt %s' and others
that used 'opt < %s'. We now change all to use 'opt < %s'. Piping in test files
is preferable as it does prevent temporary files to be written to disk. This
brings us in line with what is usus in LLVM.
llvm-svn: 216816
This replaces the use of %defaultOpts = '-basicaa -polly-prepare' with the
minimal set of passes necessary for a test to succeed. Of the test cases that
previously used %defaultOpts 76 test cases require none of these passes, 42
need -basicaa and only 2 need -polly-prepare. Our change makes this requirement
explicit.
In Polly many test cases have been using a macro '%defaultOpts' which run a
couple of preparing passes before the actual Polly test case. This macro was
introduced very early in the development of Polly and originally contained a
large set of canonicalization passes. However, as the need for additional
canonicalization passes makes test cases harder to understand and also more
fragile in terms of changes in such passes, we aim since a longer time to only
include the minimal set of passes necessary. This patch removes the last
leftovers from of %defaultOpts and brings our tests cases more in line to what
is usus in LLVM itself.
llvm-svn: 216815
Arcanist (arc) will now always run linters before uploading any new
commit to Phabricator. All errors/warnings (or their absence) will be
shown in the web interface together with a explanation by the commiter
(arcanist will ask the commiter if the build was not clean).
The linters include:
- clang-format
- spelling check
- permissions check (aka. chmod)
- filename check
- merge conflict marker check
Note, that their scope is sometimes limited (see .arclint for
details).
This commit also fixes all errors and warnings these linters reported,
namely:
- spelling mistakes and typos
- executable permissions for various text files
Differential Revision: http://reviews.llvm.org/D4916
llvm-svn: 215871
This will spill out information about LLVM-internals. However, in cases
where the name of the Value matches the name of the array in the source,
we provide more useful information. In cases where we spill internals,
the information still might help the user to pin down the correct
arrays.
The problem we face here is: The error is pinned to the debug location
of one of the offending values out of the alias set instead of all of them.
The more information we give the user about the set of aliasing
pointers the better.
llvm-svn: 215830
This reverts commit 215466 (and 215528, a trivial formatting fix).
The intention of these commits is a good one, but unfortunately they broke
our LNT buildbot:
http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-codegen-isl
Several of the cleanup changes that have been combined in this 'fixup' are
trivial and could probably be committed as obvious changes without risking to
break the build. The remaining changes are little and it should be easy to
figure out what went wrong.
llvm-svn: 215817
This reverts commit 215684. The intention of the commit is great, but
unfortunately it seems to be the cause of 14 LNT test suite failures:
http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly/builds/116
To make our buildbots and performance testers green until this issue is solved,
we temporarily revert this commit.
llvm-svn: 215816
The support is limited to signed modulo access and condition
expressions with a constant right hand side, e.g., A[i % 2] or
A[i % 9]. Test cases are modified according to this new feature and
new test cases are added.
Differential Revision: http://reviews.llvm.org/D4843
llvm-svn: 215684
There is no needed for neither 1-dimensional nor higher dimensional arrays to
require positive offsets in the outermost array dimension.
We originally introduced this assumption with the support for delinearizing
multi-dimensional arrays.
llvm-svn: 214665
+ Remove the class IslGenerator which duplicates the functionality of
IslExprBuilder.
+ Use the IslExprBuilder to create code for memory access relations.
+ Also handle array types during access creation.
+ Enable scev codegen for one of the transformed memory access tests,
thus access creation without canonical induction variables available.
+ Update one test case to the new output.
llvm-svn: 214659
The updated tests use a different context than the old ones did.
Other than that only their path and the code generation we use
changed.
llvm-svn: 214657
Use the fact that if we visit a for node first in pre and next in post order
we know we did not visit any children, thus we found an innermost loop.
+ Test case for an innermost loop with a conditional inside
llvm-svn: 213870
+ Introduced dependency type TYPE_TC_RED to represent the transitive closure
(& the reverse) of reduction dependences. These are used when we check for
reduction parallel loops.
+ Test cases including loop reversals and modulo schedules which compute
reductions in a alternated order.
llvm-svn: 213019
We move back to a simple approach where the liveout is the last must-write
statement for a data-location plus all may-write statements. The previous
approach did not work out. We would have to consider per-data-access
dependences, instead of per-statement dependences to correct it. As this adds
complexity and it seems we would not gain anything over the simpler approach
that we implement in this commit, I moved us back to the old approach of
computing the liveout, but enhanced it to also add may-write accesses.
We also fix the test case and explain why we can not perform dead code
elimination in this case.
llvm-svn: 212925
As our delinearization works optimistically, we need in some cases run-time
checks that verify our optimistic assumptions. A simple example is the
following code:
void foo(long n, long m, long o, double A[n][m][o]) {
for (long i = 0; i < 100; i++)
for (long j = 0; j < 150; j++)
for (long k = 0; k < 200; k++)
A[i][j][k] = 1.0;
}
After clang linearized the access to A and we delinearized it again to
A[i][j][k] we need to ensure that we do not access the delinearized array
out of bounds (this information is not available in LLVM-IR). Hence, we
need to verify the following constraints at run-time:
CHECK: Assumed Context:
CHECK: [o, m] -> { : m >= 150 and o >= 200 }
llvm-svn: 212198
This change is particularly useful in the code generation as we need
to know which binary operator/identity element we need to combine/initialize
the privatization locations.
+ Print the reduction type for each memory access
+ Adjusted the test cases to comply with the new output format and
to test for the right reduction type
llvm-svn: 212126
Iterate over all store memory accesses and check for valid binary reduction
candidate loads by following the operands of the stored value. For each
candidate pair we check if they have the same base address and there are no
other accesses which may overlap with them. This ensures that no intermediate
value can escape into other memory locations or is overwritten at some point.
+ 17 test cases for reduction detection and reduction dependency modeling
llvm-svn: 211957
Enabling -keep-going in ScopDetection causes expansion to an invalid
Scop candidate.
Region A <- Valid candidate
|
Region B <- Invalid candidate
If -keep-going is enabled, ScopDetection would expand A to A+B because
the RejectLog is never checked for errors during expansion.
With this patch only A becomes a valid Scop.
llvm-svn: 211875
This change will ease the transision to multiple reductions per statement as
we can now distinguish the effects of multiple reductions in the same
statement.
+ Wrapped reduction dependences are used to compute privatization dependences
+ Modified test cases to account for the change
llvm-svn: 211795
This dependency analysis will keep track of memory accesses if they might be
part of a reduction. If not, the dependences are tracked on a statement level.
The main reason to do this is to reduce the compile time while beeing able to
distinguish the effects of reduction and non-reduction accesses.
+ Adjusted two test cases
llvm-svn: 211794
Add support for generating optimization remarks after completing the
detection of Scops.
The goal is to provide end-users with useful hints about opportunities that
help to increase the size of the detected Scops in their code.
By default the remark is unspecified and the debug location is empty. Future
patches have to expand on the messages generated.
This patch brings a simple test case for ReportFuncCall to demonstrate the
feature.
Reports all missed opportunities to increase the size/number of valid
Scops:
clang <...> -Rpass-missed="polly-detect" <...>
opt <...> -pass-remarks-missed="polly-detect" <...>
Reports beginning and end of all valid Scops:
clang <...> -Rpass="polly-detect" <...>
opt <...> -pass-remarks="polly-detect" <...>
Differential Revision: http://reviews.llvm.org/D4171
llvm-svn: 211769
Due to bad habit we sometimes used a variable %defaultOpts that listed
a set of passes commonly run to prepare for Polly. None of these test cases
actually needs special preparation and only two of them need the 'basicaa' to
be scheduled. Scheduling the required alias analysis explicitly makes the test
cases clearer.
llvm-svn: 211671
We had a set of test cases that have been incomplete and XFAILED. This patch
completes a couple of the interesting ones and removes the ones which seem
redundant or not sufficiently reduced to be useful.
llvm-svn: 211670
Insert a header into the new testcase containing a sample RUN line a FIXME and
an XFAIL. Then insert the formated C code and finally the LLVM-IR without
attributes, the module ID or the target triple.
llvm-svn: 211612
We use llvm.codegen intrinsic to generate code for embedded LLVM-IR
strings. The reason we introduce such a intrinsic is that previous
clang/opt tools was NOT linked with various LLVM targets and their
AsmParsers and AsmPrinters. Since clang/opt been linked with all the
needed libraries, we no longer need the llvm.codegen intrinsic.
llvm-svn: 211573
+ Collect reduction dependences
+ Introduced TYPE_RED in Dependences.h which can be used to obtain the
reduction dependences
+ Used TYPE_RED to prevent parallelization while we do not have a privatizing
code generation
+ Relax the dependences for non-parallel code generation
+ Add privatization dependences to ensure correctness
+ 12 Test cases to check for reduction and privatization dependences
llvm-svn: 211369
We do this currently only for test cases where we have integer offsets that
clearly access array dimensions out-of-bound.
-; for (long i = 0; i < n; i++)
-; for (long j = 0; j < m; j++)
-; for (long k = 0; k < o; k++)
+; for (long i = 0; i < n - 3; i++)
+; for (long j = 4; j < m; j++)
+; for (long k = 0; k < o - 7; k++)
; A[i+3][j-4][k+7] = 1.0;
This will be helpful if we later want to simplify the access functions under the
assumption that they do not access memory out of bounds.
llvm-svn: 210179
Without this patch, the testcase would fail on the delinearization of the second
array:
; void foo(long n, long m, long o, double A[n][m][o]) {
; for (long i = 0; i < n; i++)
; for (long j = 0; j < m; j++)
; for (long k = 0; k < o; k++) {
; A[i+3][j-4][k+7] = 1.0;
; A[i][0][k] = 2.0;
; }
; }
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[3 + i0, -4 + i1, 7 + i2] };
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
Here is the output of FileCheck on the testcase without this patch:
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
^
<stdin>:26:2: note: possible intended match here
[n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[o0] };
^
It is possible to find a good delinearization for A[i][0][k] only in the context
of the delinearization of both array accesses.
There are two ways to delinearize together all array subscripts touching the
same base address: either duplicate the code from scop detection to first gather
all array references and then run the delinearization; or as implemented in this
patch, use the same delinearization info that we computed during scop detection.
llvm-svn: 210117
+ CL-option --polly-tile-sizes=<int,...,int>
The i'th value is used as a tile size for dimension i, if
there is no i'th value, the value of --polly-default-tile-size is
used
+ CL-option --polly-default-tile-size=int
Used if no tile size is given for a dimension i
+ 3 Simple testcases
llvm-svn: 209753
Tag the GPGPU codegen test cases as unsupported if the nvptx target is not
included in the current llvm build.
Contributed-by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 208779
Commit r206510 falsely advertised to fix the load cases, even though it only
fixed the store case. This commit adds the same fix for the load case including
the missing test coverage.
llvm-svn: 206577
Even tough we may want to generate a vector load, the address from which to load
still is a scalar. Make sure even if previous address computations may have been
vectorized, that the addresses are also available as scalars.
This fixes http://llvm.org/PR19469
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206510
The following example shows a non-parallel loop
void f(int a[]) {
int i;
for (i = 0; i < 10; ++i)
A[i] = A[i+5];
}
which, in case we import a schedule that limits the iteration domain
to 0 <= i < 5, becomes parallel. Previously we crashed in such cases, now we
just recognize it as parallel.
This fixes http://llvm.org/PR19435
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206318
During code preperation trivial PHI nodes (mainly introduced by lcssa) are
deleted to decrease the number of introduced allocas (==> dependences). However
simply replacing them by their only incoming value would cause the independent
block pass to introduce new allocas. To prevent this we try to share stack slots
during code preperarion, hence to reuse a already created alloca 'to demote' the
trivial PHI node. This works if we know that the value stored in this alloca
will be the incoming value of the trivial PHI at the end of the predecessor
block of this trivial PHI.
Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 205320
We explicitly specifying all filenames instead of assuming some naming
convention used by clang and opt.
Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 204726
For complex examples it may happen that we do not compute dependences. In this
case we do not want to crash, but just not detect parallel loops.
llvm-svn: 204470
This patch enables vectorization of loops containing backward array
traversal (array stride is -1).
Contributed-by: Chris Jenneisch <chrisj@codeaurora.org>
llvm-svn: 204257
In case we are at the innermost band, we try to prepare for vectorization. This
means, we look for the innermost parallel loop and strip mine this loop to the
innermost level using a strip-mine factor corresponding to the number of vector
iterations.
For whatever reason, the code that implemented this feature was broken. We now
added a comment, a test case and obviously also the right code.
llvm-svn: 203544
This is necessary to avoid test failures in the CLooG test suite due to the
recent isl update.
We also need to update two polly test cases which rely on a certain order in the
textual description that isl chooses for its sets and maps. Changes here are not
often, but we should probably switch to a check that verifies such maps are
semantically equivalent instead of represented identically.
llvm-svn: 203476
For now we only mark innermost loops for the loop vectorizer. We could later
also mark not-innermost loops to enable the introduction of openmp parallelism.
llvm-svn: 202854
In 'obsequi' we have a scop in which the current dead code elimination works,
but the generated code is way too complex. To avoid this trouble (and to not
disable the DCE entirely) we add an additional approximative step before
the actual dead code elimination. This should fix one of the two current
nightly-test issues.
Polly could be improved to handle 'obsequi' by teaching it to introduce only a
single parameter for (%1 and zext %1) which halves the number of parameters and
allows polly to derive a simpler representation for the set of live iterations.
However, this needs some time to investigate.
I will commit a test case as soon as we have a reduced one.
llvm-svn: 202010
In case we do not have valid dependences, we do not run dead code elimination or
the schedule optimizer. This fixes an infinite loop in the dead code
elimination (PR12110).
llvm-svn: 201982
Instead of giving a choice between a precise (but possibly very complex)
analysis and an approximative analysis we now use a hybrid approach which uses N
precise steps followed by one approximating step. The precision of the analysis
can be changed by increasing N. With a default of 'N' = 2, we get fully precise
results for our current test cases and should not run into performance problems
for more complex test cases. We can adjust this value when we got more
experience with this dead code elimination.
llvm-svn: 201888
We now skip the debug intrinsics which is a lot better than crashing due to
uncopied metadata references. We should step by step investigate which debug
intrinsics we can copy without trouble.
We still keep the debug location metadata.
llvm-svn: 201860
This pass eliminates loop iterations that compute results that are not used
later on. This can help e.g. in D, where the default zero-initialization is
often unnecessary if right after new values are assigned to an array.
Contributed-by: Peter Conn <conn.peter@gmail.com>
llvm-svn: 201817
We do not have a use for this information at the moment. If we need this at some
point, the "instruction -> access" mapping needs to be enhanced as a single
instruction could then possibly perform multiple accesses.
This patch allows us to build the polyhedral information for scops with scalar
dependences.
llvm-svn: 201815
In rare cases the modification of one scop can effect the validity of other
scops, as code generation of an earlier scop may make the scalar evolution
functions derived for later scops less precise. The example that triggered this
patch was a scop that contained an 'or' expression as follows:
%add13710 = or i32 %j.19, 1
--> {(1 + (4 * %l)),+,2}<nsw><%for.body81>
Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This
information was not available after the first scop was code generated (or
independent-blocks was run on it) and SCEV could not derive a precise SCEV
expression any more. This means we could not any more code generate this SCoP.
My current understanding is that there is always the risk that an earlier code
generation change invalidates later scops. As the example we have seen here is
difficult to avoid, we use this occasion to guard us against all such
invalidations.
This patch "solves" this issue by verifying right before we start working on
a detected scop, if this scop is in fact still valid. This adds a certain
overhead. However the verification we run is anyways very fast and secondly
it is only run on detected scops. So the overhead should not be very large. As
a later optimization we could detect scops only on demand, such that we need
to run scop-detections always only a single time.
This should fix the single last failure in the LLVM test-suite for the new
scev-based code generation.
llvm-svn: 201593
There does not seem to be a reason that we can not support PHI nodes outside of
the scop that reference values within the SCoP. Or at least, the attached test
case seems to do the right thing. We remove the assert for now.
llvm-svn: 200427
In rare cases, a region R which is itself not valid has an indirect child region
that is valid. When R becomes part of a valid region by expansion of another
region, then all children of R have to be erased from the set of valid regions.
This patch ensures that indirect children are erased in addition to direct
children.
Contributed-by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
Tobias: I added a reduced test case and adjusted the logic of the patch to
only recurse until the first child is found.
llvm-svn: 200411
Array base addresses need to be invariant in the region considered. The base
address has to be computed outside the region, or, when it is computed inside,
the value must not change with the iterations of the loops. For example, when a
two-dimensional array is represented as a pointer to pointers the base address
A[i] in an access A[i][j] changes with i; therefore, such regions have to be
rejected.
Contributed by: Armin Größlinger <armin.groesslinger@uni-passau.de>
llvm-svn: 200314
This is not only not necessary, but in case -03 changes this can actually
cause arbitrarily failing test cases such as, e.g., a recent change by Chandler
that caused -O3 to unroll the loop body, which made the loop we wanted to
detect disappear and consequently this test case fail.
llvm-svn: 200204
Count the number of computational steps that have been used to solve the
dependence problem and abort in case we reach the "compute-out". This ensures we
do not hang forever in cases the dependence problem is too difficult to solve.
There is just a single case in the LLVM test-suite that runs into the
compute-out. Even in this case, we can probably coalesce some of the parameters
(i32 b, i32 b zext i64, ...) to simplify the problem enough to not hit the
compute out. However, for now we set the compute out in place to address the
general issue. The compute out was choosen such that it stops on a recent laptop
after about 8 seconds.
llvm-svn: 200156
We now report the following:
$ polly-clang -O3 -mllvm -polly -mllvm -polly-report test.c -c \
-gline-tables-only
note: Polly detected an optimizable loop region (scop) in function 'foo'
test.c:2: Start of scop
test.c:3: End of scop
note: Polly detected an optimizable loop region (scop) in function 'bar'
test.c:9: Start of scop
test.c:13: End of scop
llvm-svn: 197558
When constructing a scop sometimes the exact representation of a statement or
condition would be very complex, but there is a common case which is a lot
simpler, but which is only valid under certain assumptions. The assumed context
records the assumptions taken during the construction of this scop and that need
to be code generated as a run-time test.
At the moment, we do not yet model any assumptions, but only added the
AssumedContext as well as the isl-ast generation support. As a next step,
this needs to be hooked up with the isl code generation.
if (1) /* run-time condition */
{ /* optimized code */ }
else
{ /* original code */ }
llvm-svn: 193652
SCoP invariant parameters with the different start value would deter parameter
sharing. For example, when compiling the following C code:
void foo(float *input) {
for (long j = 0; j < 8; j++) {
// SCoP begin
for (long i = 0; i < 8; i++) {
float x = input[j * 64 + i + 1];
input[j * 64 + i] = x * x;
}
}
}
Polly would creat two parameters for these memory accesses:
p_0: {0,+,256}
p_2: {4,+,256}
[j * 64 + i + 1] => MemRef_input[o0] : 4o0 = p_1 + 4i0
[j * 64 + i] => MemRef_input[o0] : 4o0 = p_0 + 4i0
These parameters only differ from start value. To enable parameter sharing,
we split the start value from SCEVAddRecExpr, so they would share a single
parameter that always has zero start value:
p0: {0,+,256}<%for.cond1.preheader>
[j * 64 + i + 1] => MemRef_input[o0] : 4o0 = 4 + p_1 + 4i0
[j * 64 + i] => MemRef_input[o0] : 4o0 = p_0 + 4i0
Such translation can make the polly-dependence much faster.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187728
In case we detect that the schedule the user wants to import is invalid we
refuse it _and_ free the isl_maps containing it.
Another bug found thanks to Rafael.
llvm-svn: 187339
We now use __isl_take to annotate the uses of the isl_set where we got the
memory management wrong.
Thanks to Rafael! His pipefail work hardened our test environment and exposed
this bug nicely.
llvm-svn: 187338
Ensure that the scalar write access corresponds to the result of a load
instruction appears after the generic read access corresponds to the load
instruction.
llvm-svn: 186419
Previously this happend to work for integers up to i64, but we got it wrong
for larger numbers. Fix this and add test cases to verify this keeps working.
Reported by: Sven Verdoolaege <skimo at kotnet dot org>
llvm-svn: 183986
When a region header is part of a loop, then all entering edges of this region
should not come from the loop but outside the region. Otherwise, the loop may be
only partially part of the region, which would cause troubles in handling
induction variables.
Currently, we can only model induction variables that are either fully part of
the scop (loop induction variable) or induction variables that are scop-
invariant (parameter). A loop that is only partially part of the
scop causes troubles, as there is no good way to handle the induction
variable in the independent blocks pass.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 183800
The original test case showed a problem with the independet blocks pass and
we decided to XFAIL it for now. Unfortunately the failure is not detected if
we build without asserts and the verification of the independent block pass
is not run. This change tests now for the actual reason of the failure and
should trigger even in a non asserts build. We did not yet solve the underlying
bug, but this should at least make the test suite behavior consistent.
llvm-svn: 183025
When the Polly code generation was written we did not correctly update the
LoopInfo data, but still claimed that the loop information is correct. This
does not only lead to missed optimizations, but it can also cause
miscompilations in case passes such as LoopSimplify are run after Polly.
Reported-by: Sergei Larin <slarin@codeaurora.org>
llvm-svn: 181987
BeforeBB
|
v
GuardBB
/ \
__ PreHeaderBB \
/ \ / |
latch HeaderBB |
\ / \ /
< \ /
\ /
ExitBB
This does not only remove the need for an explicit loop rotate pass, but it also
gives us the possibility to skip the construction of the guard condition in case
the loop is known to be executed at least once. We do not yet exploit this, but
by implementing this analysis in the isl code generator we should be able to
remove more guards than the generic loop rotate pass can. Another point is that
loop rotation can introduce additional PHI nodes, which may hide that a loop can
be executed in parallel. This change avoids this complication and will make it
easier to move the openmp code generation into a separate pass.
llvm-svn: 181986
Use the new cl::OptionCategory support to move the Polly options into a separate
option category. The aim is to hide most options and show by default only the
options a user needs to influence '-O3 -polly'. The available options probably
need some care, but here is the current status:
Polly Options:
Configure the polly loop optimizer
-enable-polly-openmp - Generate OpenMP parallel code
-polly - Enable the polly optimizer (only at -O3)
-polly-no-tiling - Disable tiling in the scheduler
-polly-only-func=<function-name> - Only run on a single function
-polly-report - Print information about the activities
of Polly
-polly-vectorizer - Select the vectorization strategy
=none - No Vectorization
=polly - Polly internal vectorizer
=unroll-only - Only grouped unroll the vectorize
candidate loops
=bb - The Basic Block vectorizer driven by
Polly
llvm-svn: 181295
In the classical (non -polly-codegen-scev) mode, we assume that we can always
recreate PHI nodes during code generation. This is not true. We can only
reconstruct them from the polyhedral information, in case the entire loop of the
PHI node is part of the SCoP and consequently the PHI node was translated in
the polyhedral description.
llvm-svn: 179674
We now support regions with multiple entries and multiple exits natively.
Regions are not needed to be simplified to single entry and single exit.
We need to XFAIL two test cases as this change increases the scop coverage
and uncoveres two failures in the independent blocks pass. The first failure
will be fixed in a subsequent commit, the second one is in the non-default
-polly-codegen-scev mode and still needs to be fixed.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179673
Regions that have multiple entry edges are very common. A simple if condition
yields e.g. such a region:
if
/ \
then else
\ /
for_region
This for_region contains two entry edges 'then' -> 'for_region' and 'else' -> 'for_region'.
Previously we scheduled the RegionSimplify pass to translate such regions into
simple regions. With this patch, we now support them natively when the region is
in -loop-simplify form, which means the entry block should not be a loop header.
Contributed by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179586
We do not only need to understand that 'k * p' is a parameter expression, but
also need to store this expression in the set of parameters. Before this patch
we wrongly stored the two individual parameters %k and %p.
Reported by: Sebastian Pop <spop@codeaurora.org>
llvm-svn: 179485
Statements with an empty iteration domain may not have a schedule assigned by
the isl schedule optimizer. As Polly expects each statement to have a schedule,
we keep the old schedule for such statements.
This fixes http://llvm.org/PR15645`
Reported-by: Johannes Doerfert <johannesdoerfert@gmx.de>
llvm-svn: 179233
Regions that have multiple exit edges are very common. A simple if condition
yields e.g. such a region:
if
/ \
then else
\ /
after
Region: if -> after
This regions contains the bbs 'if', 'then', 'else', but not 'after'. It has
two exit edges 'then' -> 'after' and 'else' -> 'after'.
Previously we scheduled the RegionSimplify pass to translate such regions into
simple regions. With this patch, we now support them natively.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179159
Fix inspired from c2d4a0627e95c34a819b9d4ffb4db62daa78dade.
Given the following code
for (i = 0; i < 10; i++) {
;
}
S: A[i] = 0
When translate the data reference A[i] in statement S using scev, we need to
retrieve the scev of 'i' at the location of 'S'. If we do not do this the
scev that we obtain will be expressed as {0,+,1}_for and will reference loop
iterators that do not surround 'S'. What we really want is the scev to be
instantiated to the value of 'i' after the loop. This value is {10}.
This used to crash in:
int loopDimension = getLoopDepth(Expr->getLoop());
isl_aff *LAff = isl_aff_set_coefficient_si(
isl_aff_zero_on_domain(LocalSpace), isl_dim_in, loopDimension, 1);
(gdb) p Expr->dump()
{8,+,8}<nw><%do.body>
(gdb) p getLoopDepth(Expr->getLoop())
$5 = 0
isl_space *Space = isl_space_set_alloc(Ctx, 0, NbLoopSpaces);
isl_local_space *LocalSpace = isl_local_space_from_space(Space);
As we are trying to create a memory access in a stmt that is outside all loops,
LocalSpace has 0 dimensions:
(gdb) p NbLoopSpaces
$12 = 0
(gdb) p Statement.BB->dump()
if.then: ; preds = %do.end
%0 = load float* %add.ptr, align 4
store float %0, float* %q.1.reg2mem, align 4
br label %if.end.single_exit
and so the scev for %add.ptr should be taken at the place where it is used,
i.e., it should be the value on the last iteration of the do.body loop, and not
"{8,+,8}<nw><%do.body>".
llvm-svn: 179148
After this commit, polly is clang-format clean. This can be tested with
'ninja polly-check-format'. Updates to clang-format may change this, but the
differences will hopefully be both small and general improvements to the
formatting.
We currently have some not very nice formatting for a couple of items, DEBUG()
stmts for example. I believe the benefit of being clang-format clean outweights
the not perfect layout of this code.
llvm-svn: 177796
Given the following code
for (i = 0; i < 10; i++) {
;
}
S: A[i] = 0
When code generating S using scev based code generation, we need to retrieve
the scev of 'i' at the location of 'S'. If we do not do this the scev that
we obtain will be expressed as {0,+,1}_for and will reference loop iterators
that do not surround 'S' and that we consequently do not know how to code
generate. What we really want is the scev to be instantiated to the value of 'i'
after the loop. This value is {10} and it can be code generated without
troubles.
llvm-svn: 177777
We now detect scops without a canonical induction variable and can generate a
polyhedral representation for them. There was no modification necessary to
code generate these scops.
llvm-svn: 177643
When using the scev based code generation, we now do not rely on the presence
of a canonical induction variable any more. This commit prepares the path to
(conditionally) disable the induction variable canonicalization pass.
llvm-svn: 177548
When doing SCEV based code generation, we ignore instructions calculating values
that are fully defined by a SCEV expression. The values that are calculated by
this instructions are recalculated on demand.
This commit improves the check to verify if certain instructions can be ignored
and recalculated on demand.
llvm-svn: 177313
In my previous commits I failed to realise that my new requires lines fully
disabled these tests. We now properly check if we are in an asserts build and
only disable the tests if assertions are not available.
Reported-by: Sean Silva <silvas@purdue.edu>
llvm-svn: 176900
This fixes issues caused by the following commit:
r176733 | jvoung | 2013-03-08 17:56:31 -0500
Disable statistics on Release builds and move tests that depend on -stats.
Reported by: Jack Howarth <howarth@bromo.med.uc.edu>
llvm-svn: 176856
We need to remove one dimension. Any is correct as long as it exists. We have
choosen for whatever reason the dimension #dims - 2. This is incorrect if
there is just one dimension. For CLooG this case did never happen. For isl
however, the case can happen and causes undefined behavior including crashes.
We choose now always the last dimension #dims - 1. We could have choosen
dimension '0' but the last dimension is what we remove conceptionally in the
algorithm, so it seems better to actually program it that way.
While at it remove another piece of undefined behavior.
llvm-svn: 174894
Similar to LLVM we now follow the policy of only having LLVM-IR level tests in
the Polly test suite. Testing for miscompilation of larger programs should be
done with the llvm test suite.
llvm-svn: 167255
Instead of calculating exact value (flow) dependences, it is also possible to
calculate memory based dependences. Sometimes memory based dependences are a lot
easier to calculate. To evaluate the benefits, we add an option to calculate
memory based dependences (use -polly-value-dependences=false).
llvm-svn: 167251
The detection of values that need to be copied in to the generated OpenMP
subfunction also detects the array base addresses needed in the SCoP. Hence, it
is not necessary to unconditionally copy all the base addresses to the generated
function.
Test cases are modified to reflect this change. Arrays which are global
variables do not occur in the struct passed to the subfunction anymore. A test
case for base address copy-in is added in copy_in_array.{c,ll}.
Committed with slight modifications
Contributed by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
llvm-svn: 167215
In addition to the arrays and clast variables a SCoP statement may also refer to
values defined before the SCoP or to function arguments. Detect these values and
add them to the set of values passed to the function generated for OpenMP
parallel execution of a clast.
Committed with additional test cases and some refactoring.
Contributed by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
llvm-svn: 167214
When generating OpenMP or GPGPU code the original ValueMap and ClastVars must be
kept. We already recovered the original ClastVars by reverting the changes, but
we did not keep the content of the ValueMap. This patch keeps now an explicit
copy of both maps and restores them after generating OpenMP or GPGPU code.
This is an adapted version of a patch contributed by:
Armin Groesslinger <armin.groesslinger@uni-passau.de>
llvm-svn: 167213
On Linux there is no difference between shared modules and shared libaries, both
are '.so' files. However, on darwin only shared modules are '.so' files. Shared
libraries have the '.dynlib' suffix.
Fix test cases on darwin by expecting a shared module suffix for Polly instead
of a shared library suffix.
This fixes PR14135
Reported by: Jack Howarth <howarth@bromo.med.uc.edu>
llvm-svn: 166402
The bug was within isl. To fix it, we simply update the isl version that
is used by Polly. We still have some changes within Polly to be able to
write a proper test case.
Reported-by: Sameer Sahasrabuddhe <Sameer.Sahasrabuddhe@amd.com>
llvm-svn: 166021
Previously isl always generated '<=' or '>='. However, in many cases '<' or '>'
leads to simpler code. This commit updates isl and adds the relevant code
generation support to Polly.
llvm-svn: 166020
At the moment we can handle such arrays only by conservatively assuming that
each access to such an array may touch any element in the array. It would be
great if we could improve Polly/LLVM at some point, such that we can
recover the multi-dimensionality of the accesses.
llvm-svn: 163619
This ensures that the isl sets/maps we operate on have the same parameter
dimensions. Operations on objects with different parameter dimensions are not
allow and trigger assertions.
llvm-svn: 163618
Translate the selected parallel loop body into a ptx string and run it with the
cuda driver API. We limit this preliminary implementation to target the
following special test cases:
- Support only 2-dimensional parallel loops with or without only one innermost
non-parallel loop.
- Support write memory access to only one array in a SCoP.
The patch was committed with smaller changes to the build system:
There is now a flag to enable gpu code generation explictly. This was required
as we need the llvm.codegen() patch applied on the llvm sources, to compile this
feature correctly. Also, enabling gpu code generation does not require cuda.
This requirement was removed to allow 'make polly-test' runs, even without an
installed cuda runtime.
Contributed by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 161239
I did not take into account, that this patch fails to compile without the
llvm.codegen patch applied. This breaks buildbots.
I revert this until we found a solution to commit this without buildbots
complaining.
This reverts commit cb43ab80e94434e780a66be3b9a6ad466822fe33.
llvm-svn: 160165
Translate the selected parallel loop body into a ptx string and run it
with cuda driver API. We limit this preliminary implementation to
target the following special test cases:
- Support only 2-dimensional parallel loops with or without only one
innermost non-parallel loop.
- Support write memory access to only one array in a SCoP.
Contributed by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 160164
Derive the maximal and minimal values of a parameter from the type it has. Add
this information to the scop context. This information is needed, to derive
optimal types during code generation.
llvm-svn: 157245
Johannes Doerfert