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
These write are important as they will force the scheduling and code
generation of an otherwise trivial statement and also impose an order of
execution needed to guarantee the correct final value for a scalar in a loop.
Added test case modeled after ClamAV/clamscan.
llvm-svn: 228847
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
With this patch Polly is always GPL-free (no dependency on GMP any more). As a
result, building and distributing Polly will be easier. Furthermore, there is no
need to tightly coordinate isl and Polly releases anymore.
We import isl b3e0fa7a05d as well as imath 4d707e5ef2. These are the git
versions Polly currently was tested with when using utils/checkout_isl.sh. The
imported libraries are both MIT-style licensed.
We build isl and imath with -fvisibility=hidden to avoid clashes in case other
projects (such as gcc) use conflicting versions of isl. The use of imath can
temporarily reduce compile-time performance of Polly. We will work on
performance tuning in tree.
Patches to isl should be contributed first to the main isl repository and can
then later be reimported to Polly.
This patch is also a prerequisite for the upcoming isl C++ interface.
llvm-svn: 228193
The support is currently limited as we only allow them in the input but do
not emit them in the transformed SCoP due to the possible semantic changes.
Differential Revision: http://reviews.llvm.org/D5225
llvm-svn: 227054
lets 'ninja check-polly' pass for me with a lib64 build of LLVM.
I've not updated the standalone side as I don't use it and don't have an
easy way to test any changes I've made there. I mostly wanted to be able
to actually run Polly's tests when I update its use of LLVM's APIs
during my refactorings on the (very unlikely) off chance that I make
a change which compiles but does the wrong thing.
llvm-svn: 226420
This change ensures that the values that represent the array size of a
multi-dimensional access are correctly sign-extended when used to compute a
memory address used in the run-time alias check.
To make the test case more readable, we name the instructions that we generate.
llvm-svn: 225818
The max loop depth was incorrectly computed for scops that contain a
block from a loop but do not contain the entire loop. We need to
check that the full loop is contained in the region when computing
the max loop depth.
These scops occur when a region containing an inner loop is expanded
to include some blocks from the outer loop, but it cannot be fully
expanded to contain the outer loop because the region containing the
outer loop is invalid.
Differential Revision: http://reviews.llvm.org/D6913
llvm-svn: 225812
This support is still incomplete and consequently hidden behind a switch that
needs to be enabled. One problem is ATM that we incorrectly interpret very large
unsigned values as negative values even if used in an unsigned comparision.
llvm-svn: 225480
AF = dyn_cast<SCEVAddRecExpr>(Pair.second) may be NULL for some SCEVs that we do
not support. When reporting the error we still want to pass a pointer that is
known to always be non-NULL.
I do not yet have a test case for this, unfortunately.
llvm-svn: 225461
This would add another library dependency to Polly. In many cases the
JSCoP interface we have should be enough and an external JSCoP <> OpenSCoP
converter could be written. We can reconsider this if new use cases show up.
llvm-svn: 225390
We previously used a Twine here, but as pointed out by David Blaikie
and Mehdi Amini storing a temporary StringRef in a Twine is not a good
idea, as the StringRef will be freed before the Twine is used leaving
a Twine that points to uninitialized memory. We now make it explicit that
we use a StringRef here.
llvm-svn: 225342
We should reconsider this after having switched to imath (instead of gmp)
as the default isl backend, as this would allow us to keep a copy of isl
in the polly svn and to consequently make it easier to distribute Polly.
llvm-svn: 225262
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
The dead code elimination is a pass that looks very promising, but needs some
more compile-time tuning before enabling it by default seems sensible.
llvm-svn: 223965
This simplifies the construction of the input for the reduction dependence
computation and at the same time removes an assumption that expects the schedule
to be of 2D + 1 form (the odd dimensions giving textual order, the even
dimensions the loop iterations).
llvm-svn: 223621
Isl now specifically marks modulo operations that are compared against zero.
They can be implemented with the C/LLVM remainder operation.
We also update a couple of test cases where the output of isl has slightly
changed.
llvm-svn: 223607
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
This fixes LINK_POLLY_INTO_TOOLS=ON builds, which previously failed with:
CMake Error: install(EXPORT "LLVMExports" ...) includes target "opt" which
requires target "Polly" that is not in the export set.
CMake Error: install(EXPORT "LLVMExports" ...) includes target "bugpoint" which
requires target "Polly" that is not in the export set.
llvm-svn: 222977
In TempScopInfo::buildCondition we extract the conditions to guard the
BB *in addition of* loop bounds. This means we should only consider the
conditions in the paths (in CFG) that do not contain cycles (loops).
At the same time, we set the invert flag if the FalseBB of the current
branch dominates our target BB to indicate that we reach the target BB
with an inverted condition from the current branch.
In this case, the path from the FalseBB contains a cycle if the FalseBB
is the target of a backedge. The conditions implied by such a path should
not be consider. We can identify such a case by checking if the TrueBB
also dominates our target BB, which means we can also reach our target
BB from the TrueBB, without going through the backedge.
llvm-svn: 222907
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
SCEV based code generation allows Polly to detect and generate code for loops
that do not have an explicit induction variable, but only virtual induction
variables given by SCEV.
Being able to do so has two main benefits:
- We can detect more scops by default
- We require less canonicalization before Polly, which means we get closer
to our goal of not touching the IR before analyzing its properties.
Specifically, we do not need to run -polly-indvars to introduce explicit
canonical induction variables.
This switch became possible as both the isl code generation and -polly-parallel
are LNT error free with SCEV based code generation and the isl ast generator.
llvm-svn: 222113
This patch includes tests where we actually need to adjust the CHECK lines
for SCEV based code generation. Besides these adjustments we add explicit
calls to -polly-codegen-scev=[true|false] and make sure we test both cases.
llvm-svn: 222112
This prevents SCEVs to reference values not valid any more and as a consequence
solves a bug where such values reintroduced during ast generation caused the
independent blocks pass to fail validation.
http://llvm.org/PR21204
llvm-svn: 222103
The isl based backend has been tested since a long time and with the recently
commited OpenMP support the last missing piece of functionality was ported from
the CLooG backend.
The isl based backend gives us interesting new functionality:
- Run-time alias checks (enabled by default)
Optimize scops that contain possibly aliasing pointers. This feature has
largely increased the number of loop nests we consider for optimization.
Thanks Johannes!
- Delinearization (not yet enabled by default)
Model accesses to multi-dimensional arrays precisely. This will allow us to
understand kernels with multi-dimensional VLAs written in Julia, boost::ublas,
coremark or C99.
Thanks Sebastian!
- Generation of higher quality code
Sven and me spent a long time to optimize the quality of the generated code. A
major focus were expressions as they result from modulos/divisions or
piecewise affine expressions (a ? b : c).
- Full/Partial tile separation, polyhedral unrolling
The isl code generation provides functionality to generate specialized code
for core and cleanup loops and to specialize code using polyhedral context
information while unrolling statements.
(not yet exploited in Polly)
- Modifieable access functions
We can now use standard isl functionality to remap memory accesses to new
data locations. A standard use case is the use of shared memory, where
accesses to a larger region in global memory need to be mapped to a smaller
shared memory region using a modulo mapping.
(not yet exploited in Polly)
The cloog based code generation is still available for comparision, but is
scheduled for removal.
llvm-svn: 222101
Instead of parallelizing every parallel outermost loop, we now use a very
minimalistic cost model. Specifically, we assume innermost loops are not
worth parallelising and all non-innermost loops are.
When parallelizing all loops in LNT we got several slowdowns/timeouts due to
us parallelizing innermost loops that are executed only a couple of times
(number of iterations not known statically). With this basic heuristic enabled
LNT does not show any more timeouts, while several interesting loops are still
parallelized.
There are many ways to obtain an improved heuristic. Constructing such an
improvide heuristic from a position of minimal slow-down and zero code size
increase seems to be the best, as it allows us to track progress on LNT.
llvm-svn: 222096
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
Polly was accidently modifying a debug info metadata node when
attempting to generate a new unique metadata node for the loop id.
The problem was that we had dwarf metadata that referred to a
metadata node with a null value, like this:
!6 = ... some dwarf metadata referring to !7 ...
!7 = {null}
When we attempt to generate a new metadata node, we reserve the
first space for self-referential node by setting the first argument
to null and then mutating the node later to refer to itself.
However, because the nodes are uniqued based on pointer values, when
we get the new metadata node it actually referred to an existing
node (!7 in the example). When we went to modify the metadata to
point to itself, we were accidently mutating the dwarf metatdata. We
ended up in this situation:
!6 = ... some dwarf metadata referring to !7 ...
!7 = {!7}
and this causes an assert when generating the debug info. The fix is
simple, we just need to use a unique value when getting a new
metadata node. The MDNode::getTemporary() provides exactly the API
we need (and it is used in clang to generate the unique nodes).
Differential Revision: http://reviews.llvm.org/D6174
llvm-svn: 221550
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
When our RuntimeDebugBuilder calles fflush(NULL) to flush all output streams, it
is important that the types we use in the call match the ones used in a
declaration of fflush possible already available in the translation unit.
As we just pass on a NULL pointer, the type of the pointer value does not really
matter. However, as LLVM complains in case of mismatched types, we make sure
to create a NULL pointer of identical type.
No test case, as RuntimeDebugBuilder is not permanently used in Polly. Calls to
it are until now only used to add informative output during debugging sessions.
llvm-svn: 221251
This reverts commit r221159, as clang-format is again back to its old behaviour
and we do not cause any buildbot error messages any more.
llvm-svn: 221189
This should silence the buildbots until we understand if the clang-format
changes in r221125 have been intentional. See reply on cfe-commits for details.
llvm-svn: 221159
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
Originally we have needed this code to map the isl_id of an array to its base
pointer. However, as now the isl_id contains a reference to the array itself we
obtain the base pointer from this isl_id and we do not need to add this
information to the IDToValue map.
llvm-svn: 220876
The description of the parameter value passed to -enable-polly-aligned did
not make any sense at all, but was just a leftover coming from when this option
was copied form -enable-polly-openmp. We just drop it as the option description
gives sufficient information already.
llvm-svn: 220445
This makes sure we consistently use dbgs() when printing debug output.
Previously, the code just mixed calls to isl_*_dump() with printing to dbgs()
and was relying for both methods to interact in predictable ways (same output
stream, no unexpected reordering of outputs).
llvm-svn: 220443
By adding braces into the DEBUG statement we can make clang-format format code
such as:
DEBUG(stmt1(); stmt2())
as multi-line code:
DEBUG({
stmt1();
stmt2();
});
This makes control-flow in debug statements easier to read.
llvm-svn: 220441
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
We restricted the new access functions to be a subset of the old one
because we want to keep the alignment, however if the alignment is
"not special", thus the default for the type, we can allow any access.
Differential Revision: http://reviews.llvm.org/D5680
llvm-svn: 219503
In case the pieceweise affine function used to create an isl_ast_expr
had empty cases (e.g., with contradicting constraints on the
parameters), it was possible that the condition of the isl_ast_expr
select was not a comparison but a constant (thus of type i64).
This patch does two thing:
1) Handle the case the condition of a select is not a i1 type like C.
2) Try to simplify the pieceweise affine functions for the min/max
access when we generate runtime alias checks. That step can often
remove empty or redundant cases as well as redundant constrains.
This fixes bug: http://llvm.org/PR21167
Differential Revision: http://reviews.llvm.org/D5627
llvm-svn: 219208
-Wcomment complained about a "multi-line comment" caused by the
ascii art used in ScopHelper to describe the CFG.
Differential Revision: http://reviews.llvm.org/D5618
llvm-svn: 219207
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
Update debug info testcases for the LLVM metadata schema change in
r219010 to fold metadata constant operands into a single `MDString`.
Part of PR17891.
llvm-svn: 219019
+ 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
This also forbids the json importer to access other memory locations
than the original instruction as we to reuse the alignment of the
original load/store.
Differential Revision: http://reviews.llvm.org/D5560
llvm-svn: 218883
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
arc unit will now show the number of consecutive tests with the same
result instead of printing a "." for each one. Due to the number of
tests the "dots" didn't fit in one line any more. Furthermore the
result list is shortened, only non passing tests or tests taking
longer than a time threshold (50ms) will be reported (both to the user
and to phabricator).
llvm-svn: 218826
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
We use a parametric abstraction of the domain to split alias groups
if accesses cannot be executed under the same parameter evaluation.
The two test cases check that we can remove alias groups if the
pointers which might alias are never accessed under the same parameter
evaluation and that the minimal/maximal accesses are not global but
with regards to the parameter evaluation.
Differential Revision: http://reviews.llvm.org/D5436
llvm-svn: 218758
Johannes Doerfert