When we generate code for a whole region we have to respect dominance
and update it too.
The first is achieved with multiple "BBMap"s. Each copied block in the
region gets its own map. It is initialized only with values mapped in
the immediate dominator block, if this block is in the region and was
therefor already copied. This way no values defined in a block that
doesn't dominate the current one will be used.
To update dominance information we check if the immediate dominator of
the original block we want to copy is in the region. If so we set the
immediate dominator of the current block to the copy of the immediate
dominator of the original block.
llvm-svn: 230774
This is the code generation for region statements that are created
when non-affine control flow was present in the input. A new
generator, similar to the block or vector generator, for regions is
used to traverse and copy the region statement and to adjust the
control flow inside the new region in the end.
llvm-svn: 230340
This allows us to model non-affine regions in the SCoP representation.
SCoP statements can now describe either basic blocks or non-affine
regions. In the latter case all accesses in the region are accumulated
for the statement and write accesses, except in the entry, have to be
marked as may-write.
Differential Revision: http://reviews.llvm.org/D7846
llvm-svn: 230329
With this patch we allow the SCoP detection to detect regions as SCoPs
which have non-affine control flow inside. All non-affine regions are
tracked and later accessible to the ScopInfo.
As there is no real difference, non-affine branches as well as
floating point branches are covered (and both called non-affine
control flow). However, the detection is restricted to
overapproximate only loop free regions.
llvm-svn: 230325
Scops that only read seem generally uninteresting and scops that only write are
most likely initializations where there is also little to optimize. To not
waste compile time we bail early.
Differential Revision: http://reviews.llvm.org/D7735
llvm-svn: 229820
namespace and header rather than the top-level header and using
declarations. These helpers impede modular builds and are going away.
Migrating away from them will also be necessary to start mixing in any
usage of the new pass manager.
llvm-svn: 229091
This allows us to skip ast and code generation if we did not optimize
a SCoP and will not generate parallel or alias annotations. The
initial heuristic to exit is simple but allows improvements later on.
All failing test cases have been modified to disable early exit, thus
to keep their coverage.
Differential Revision: http://reviews.llvm.org/D7254
llvm-svn: 228851
This change has two main purposes:
1) We do not use a static interface to hide an object we create and
destroy for every basic block we copy.
2) We allow the BlockGenerator to store information between calls to
the copyBB method. This will ease scalar/phi code generation
later on.
While a lot of method signatures were changed this should not cause
any real behaviour change.
Differential Revision: http://reviews.llvm.org/D7467
llvm-svn: 228443
This allows us to model PHI nodes in the polyhedral description
without demoting them. The modeling however will result in the
same accesses as the demotion would have introduced.
Differential Revision: http://reviews.llvm.org/D7415
llvm-svn: 228433
Schedule dimensions that have the same constant value accross all statements do
not carry any information, but due to the increased dimensionality of the
schedule cost compile time. To not pay this cost, we remove constant dimensions
if possible.
llvm-svn: 225067
Without updating dependences we may lose implicit transitive dependences for
which all explicit dependences have gone through the statement iterations we
have just eliminated.
No test case. We should probably implement a -verify-dependences option.
This fixes llvm.org/PR21227
llvm-svn: 224459
This commit drops the Cloog support for Polly. The scripts and
documentation are changed to only use isl as prerequisity. In the code
all Cloog specific parts have been removed and all relevant tests have
been ported to the isl backend when it was created.
llvm-svn: 223141
Polly had a copy of this pass to create the canonical induction variables
necessary for the non-scev-based code generation. As we now always use SCEV
based code generation, canonical induction variables are not needed any more.
llvm-svn: 222979
SCEV based code generation has been the default for two weeks after having
been tested for a long time. We now drop the support the non-scev-based code
generation.
llvm-svn: 222978
In case a GEP instruction references into a fixed size array e.g., an access
A[i][j] into an array A[100x100], LLVM-IR does not guarantee that the subscripts
always compute values that are within array bounds. We now derive the set of
parameter values for which all accesses are within bounds and add the assumption
that the scop is only every executed with this set of parameter values.
Example:
void foo(float A[][20], long n, long m {
for (long i = 0; i < n; i++)
for (long j = 0; j < m; j++)
A[i][j] = ...
This loop yields out-of-bound accesses if m is at least 20 and at the same time
at least one iteration of the outer loop is executed. Hence, we assume:
n <= 0 or m <= 20.
Doing so simplifies the dependence analysis problem, allows us to perform
more optimizations and generate better code.
TODO: The location where the GEP instruction is executed is not necessarily the
location where the memory is actually accessed. As a result scanning for GEP[s]
is imprecise. Even though this is not a correctness problem, this imprecision
may result in missed optimizations or non-optimal run-time checks.
In polybench where this mismatch between parametric loop bounds and fixed size
arrays is common, we see with this patch significant reductions in compile time
(up to 50%) and execution time (up to 70%). We see two significant compile time
regressions (fdtd-2d, jacobi-2d-imper), and one execution time regression
(trmm). Both regressions arise due to additional optimizations that have been
enabled by this patch. They can be addressed in subsequent commits.
http://reviews.llvm.org/D6369
llvm-svn: 222754
This backend supports besides the classical code generation the upcoming SCEV
based code generation (which the existing CLooG backend does not support
robustly).
OpenMP code generation in the isl backend benefits from our run-time alias
checks such that the set of loops that can possibly be parallelized is a lot
larger.
The code was tested on LNT. We do not regress on builds without -polly-parallel.
When using -polly-parallel most tests work flawlessly, but a few issues still
remain and will be addressed in follow up commits.
SCEV/non-SCEV codegen:
- Compile time failure in ldecod and TimberWolfMC due a problem in our
run-time alias check generation triggered by pointers that escape through
the OpenMP subfunction (OpenMP specific).
- Several execution time failures. Due to the larger set of loops that we now
parallelize (compared to the classical code generation), we currently run
into some timeouts in tests with a lot loops that have a low trip count and
are slowed down by parallelizing them.
SCEV only:
- One existing failure in lencod due to llvm.org/PR21204 (not OpenMP specific)
OpenMP code generation is the last feature that was only available in the CLooG
backend. With the isl backend being the only one supporting features such as
run-time alias checks and delinearization, we will soon switch to use the isl
ast generator by the default and subsequently remove our dependency on CLooG.
http://reviews.llvm.org/D5517
llvm-svn: 222088
We introduces a new flag -polly-parallel and use it to annotate the for-nodes in
the isl ast that we want to execute thread parallel (e.g., using OpenMP). We
previously already emmitted openmp annotations, but we did this for various
kinds of parallel loops, including some which we can not run in parallel.
With this patch we now have three annotations:
1) #pragma known-parallel [reduction]
2) #pragma omp for
3) #pragma simd
meaning:
1) loop has no loop carried dependences
2) loop will be executed thread-parallel
3) loop can possibly be vectorized
This patch introduces 1) and reduces the use of 2) to only the cases where we
will actually generate thread parallel code.
It is in preparation of openmp code generation in our isl backend.
Legacy:
- We also have a command line option -enable-polly-openmp. This option controls
the OpenMP code generation in CLooG. It will become an alias of
-polly-parallel after the CLooG code generation has been dropped.
http://reviews.llvm.org/D6142
llvm-svn: 221479
This patch moves the SCEV based (re)generation of values before the checking for
scop-constant terms. It enables us to provide SCEV based replacements, which
are necessary to correctly generate OpenMP subfunctions when using the SCEV
based code generation.
When recomputing a new value for a value used in the code of the original scop,
we previously directly returned the same original value for all scop-constant
expressions without even trying to regenerate these values using our SCEV
expression. This is correct when the newly generated code remains fully in the
same function, however in case we want to outline parts of the newly generated
scop into subfunctions, this approach means we do not have any opportunity to
update these values in the SCEV based code generation. (In the non-SCEV based
code generation, we can provide such updates through the GlobalMap). To ensure
we have this opportunity, we first try to regenerate scalar terms with our SCEV
builder and will only return scop-constant expressions if SCEV based code
generation was not possible.
This change should not affect the results of the existing code generation
passes. It only impacts the upcoming OpenMP based code generation.
This commit also adds a test case. This test case passes before and after this
commit. It was added to ensure test coverage for the changed code.
llvm-svn: 221393
There was no good reason why this code was split accross two functions.
In subsequent changes we will change the order in which values are looked up.
Doing so would make the split into two functions even more arbitrary.
We also slightly improve the documentation.
llvm-svn: 221388
We will use ScalarEvolution in the ScopInfo.cpp to get the loop trip
count, not cache it in the TempScop object.
Differential Revision: http://reviews.llvm.org/D6070
llvm-svn: 221035
Now MaxLoopDepth only lives in Scops not in TempScops anymore.
This is the first part of a series of changes to make TempScops
obsolete.
Differential Revision: http://reviews.llvm.org/D6069
llvm-svn: 221026
This patch changes the RegionSet type used in ScopDetection from a
std::set to a llvm::SetVector. The reason for the change is to
ensure deterministic output when printing the result of the
analysis. We had a windows buildbot failure for the modified test
because the output was coming in a different order.
Only one test case needed to be modified for this change. We could
use CHECK-DAG directives instead of CHECK in the analysis test cases
because the actual order of scops does not matter, but I think that
change should be done in a separate patch that modifies all the
appliciable tests. I simply modified the test to reflect the
expected deterministic output.
Differential Revision: http://reviews.llvm.org/D5897
llvm-svn: 220423
This patch does not change the semantic on it's own. However, the
dependence analysis as well as dce will now use the newest available
access relation for each memory access, thus if at some point the json
importer or any other pass will run before those two and set a new
access relation the behaviour will be different. In general it is
unclear if the dependence analysis and dce should be run on the old or
new access functions anyway. If we need to access the original access
function from the outside later, we can expose the getter again.
Differential Revision: http://reviews.llvm.org/D5707
llvm-svn: 219612
This resolved the issues with delinearized accesses that might alias,
thus delinearization doesn't deactivate runtime alias checks anymore.
Differential Revision: http://reviews.llvm.org/D5614
llvm-svn: 219078
This class allows to store information about the arrays in the SCoP.
For each base pointer in the SCoP one object is created storing the
type and dimension sizes of the array. The objects can be obtained via
the SCoP, a MemoryAccess or the isl_id associated with the output
dimension of a MemoryAccess (the description of what is accessed).
So far we use the information in the IslExprBuilder to create the
right base type before indexing into the base array. This fixes the
bug http://llvm.org/bugs/show_bug.cgi?id=21113 (both test cases are
included). On top of that we can now build runtime alias checks for
delinearized arrays as the dimension sizes are also part of the
ScopArrayInfo objects.
Differential Revision: http://reviews.llvm.org/D5613
llvm-svn: 219077
+ Generalized function names and comments
+ Removed OpenMP (omp) from the names and comments
+ Use common names (non OpenMP specific) for runtime library call creation
methodes
+ Commented the parallel code generator and all its member functions
+ Refactored some values and methodes
Differential Revision: http://reviews.llvm.org/D4990
llvm-svn: 219003
The LoopAnnotator doesn't annotate only loops any more, thus it is
called ScopAnnotator from now on.
This also removes unnecessary polly:: namespace tags.
llvm-svn: 218878
The command line flag -polly-annotate-alias-scopes controls whether or not
Polly annotates alias scopes in the new SCoP (default ON). This can improve
later optimizations as the new SCoP is basically an alias free environment for
them.
llvm-svn: 218877
This change allows to annotate all parallel loops with loop id metadata.
Furthermore, it will annotate memory instructions with
llvm.mem.parallel_loop_access metadata for all surrounding parallel loops.
This is especially usefull if an external paralleliser is used.
This also removes the PollyLoopInfo class and comments the
LoopAnnotator.
A test case for multiple parallel loops is attached.
llvm-svn: 218793
If too many parameters are involved in accesses used to create RTCs
we might end up with enormous compile times and RTC expressions.
The reason is that the lexmin/lexmax is dependent on all these
parameters and isl might need to create a case for every "ordering"
of them (e.g., p0 <= p1 <= p2, p1 <= p0 <= p2, ...).
The exact number of parameters allowed in accesses is defined by the
command line option -polly-rtc-max-parameters=XXX and set by default
to 8.
Differential Revision: http://reviews.llvm.org/D5500
llvm-svn: 218566
This change will build all alias groups (minimal/maximal accesses
to possible aliasing base pointers) we have to check before
we can assume an alias free environment. It will also use these
to create Runtime Alias Checks (RTC) in the ISL code generation
backend, thus allow us to optimize SCoPs despite possibly aliasing
pointers when this backend is used.
This feature will be enabled for the isl code generator, e.g.,
--polly-code-generator=isl, but disabled for:
- The cloog code generator (still the default).
- The case delinearization is enabled.
- The case non-affine accesses are allowed.
llvm-svn: 218046
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
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
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
Store the llvm::Value pointers of the AliasSet instead of the AliasSet
itself.
We have to be careful about changed IR when the message is generated,
because the Value pointers might not exist anymore. This would render
the Diagnostic invalid. For now we just assert there.
Simply do not retreive a diagnostic message after the IR has changed
it's not valid information anyway.
llvm-svn: 215625
Remove the PoCC and ScopLib support from Polly as we do not have a
user/maintainer for it.
Differential Revision: http://reviews.llvm.org/D4871
llvm-svn: 215563
Use the explicit analysis if possible, only for splitBlock we will continue
to use the Pass * argument. This change allows us to remove the getAnalysis
calls from the code generation.
llvm-svn: 215121
+ 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
+ Split all reduction dependences and map them to the causing memory accesses.
+ Print the types & base addresses of broken reductions for each "reduction
parallel" marked loop (OpenMP style).
+ 3 test cases to show how reductions are now represented in the isl ast.
The mapping "(ast) loops -> broken reductions" is also needed to find the
memory accesses we need to privatize in a loop.
llvm-svn: 214489
+ Perform the parallelism check on the innermost loop only once.
+ Inline the markOpenmpParallel function.
+ Rename all IslAstUserPayload * into Payload to make it consistent.
llvm-svn: 214448
+ Renamed context into build when it's the isl_ast_build
+ Use the IslAstInfo functions to extract the schedule of a node
+ Use the IslAstInfo functions to extract the build/context of a node
+ Move the payload struct into the IslAstInfo class
+ Use a constructor and destructor (also new and delete) to
allocate/initialize the payload struct
llvm-svn: 213792
Offer the static functions to extract information out of an IslAst for node
as members of IslAstInfo not as top level entities.
+ Refactor common code
+ Add isParallel and isReductionParallel
+ Rename IslAstUser to IslAstUserPayload to make it clear this is just a (or
the) payload struct.
llvm-svn: 213272
+ 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
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
To translate the old induction variables as they exist before Polly to new
new induction variables introduced during AST code generation we need to
generate code that computes the new values from the old ones. We can do this
by just looking at the arguments isl generates in each scheduled statement.
Example:
// Old
for i
S(i)
// New
for c0
for c1
S(c0 + c1)
To get the value of i, we need to compute 'c0 + c1'. This expression is readily
available in the user statements generated by isl and just needs to be
translated to LLVM-IR.
This replaces an old confusing construct that constructed during ast generation
an isl multi affine expression that described this relation and which was then
again ast generated for each statement and argument when translating the isl ast
to LLVM-IR. This approach was difficult to understand and the additional ast
generation calls where entirely redundant as isl provides the relevant
expressions as arguments of the generated user statements.
llvm-svn: 212186
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
Johannes Doerfert