This patch enables vectorization of loops containing backward array
traversal (array stride is -1).
Contributed-by: Chris Jenneisch <chrisj@codeaurora.org>
llvm-svn: 204257
This ensures that the polly passes get properly registered both, when using
polly as a loadable module and when directly linking it into clang/opt/bugpoint.
llvm-svn: 204255
1) The isl_int -> isl_val changes are the ones Tobias suggested.
One additional isl_val_free is added (and needed)
2) Three scoplib_vector_free are added, maybe we would need even
more (and matrix_free) but it's hard to place them right.
3) Cleaned the includes (and removed 'extern C')
This fixes the broken compilation for the scoplib import and export.
Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 203500
We currently need to always name instructions, as the polly test suite currently
matches for certain names. We should improve the test suite at some point.
This fixes 'make check-polly' in NDEBUG builds.
llvm-svn: 202855
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
PollyIRBuilder is currently just a typedef to IRBuilder<>. Consequently, this
change should not affect behavior. In subsequent patches we will extend its
functionality to emit loop.parallel metadata.
llvm-svn: 202853
This fixes the buildbots who failed, because the linker eliminated most of the
Polly functionality when building without BUILD_SHARED_LIBS=ON.
Besides fixing the build, this change also brings additional functionality. With
the new separation between the general polly libraries and the functionality for
the polly module, it is now possible to link polly directly into a tool instead
of using requiring users to load a shared library.
llvm-svn: 202762
clang-formats behaviour has changed for a couple of C++11 formattings. We adapt
Polly to ensure our formatting checks are clean again.
llvm-svn: 202650
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
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
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
The MayAliasSet class is currently not used and just confuses people. We can
reintroduce it in case need a more precise tracking of alias sets.
llvm-svn: 201191
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 ModulePass schedules the set of Polly canonicalization passes. It is a
debugging tool that can be used to preoptimize .ll files for Polly processing.
llvm-svn: 198376
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
Split the old getNewValue into two parts:
1. The function "lookupAvailableValue" that return the new version of
the instruction which is already available.
2. The function calls "lookupAvailableValue", and tries to generate
the new version if it is not available yet.
llvm-svn: 187114
String operations resulted by raw_string_ostream in the INVALID macro can lead
to significant compile-time overhead when compiling large size source code.
This is because raw_string_ostream relies on TypeFinder class, whose
compile-time cost increases as the size of the module increases. This patch
targets to ensure that it only track detection failures if actually needed.
In this way, we can avoid expensive string operations in normal execution.
With this patch file, the relative compile-time cost of Polly-detect pass does
not increase even when compiling very large size source code.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187102
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
1. Do not allow creating new memory access record in the InstructionToAccess map
on the fly in function getAccessFor.
2. Do not allow user to modify the memory accesses returned by getAccessFor
during the code generation process.
llvm-svn: 185253
isl recently introduced isl_val as an abstract interface to represent arbitrary
precision numbers. This interface superseeds the old isl_int interface. In
contrast to the old interface which implemented arbitrary precision arithmetic
using macros that forward to the gmp library, the new library hides the math
library implementation in isl. This allows us to switch the math library used by
isl without affecting users such as Polly.
llvm-svn: 184529
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
Tobias Grosser