| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
We rename the Dependences pass to DependenceInfo as a first step to a
caching pass policy. The new DependenceInfo pass will later provide
"Dependences" for a SCoP.
To keep consistency the test folder is renamed too.
llvm-svn: 231308
|
|
|
|
| |
llvm-svn: 230899
|
|
|
|
|
|
| |
This is the first step in the interface simplification.
llvm-svn: 230897
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 222559
|
|
|
|
| |
llvm-svn: 221982
|
|
|
|
| |
llvm-svn: 220446
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ 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
|
|
|
|
| |
llvm-svn: 214061
|
|
|
|
|
|
|
|
|
|
| |
+ 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
|
|
|
|
| |
llvm-svn: 212609
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 211803
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
- Remove the statement reduction like property
+ Add the reduction like property to memory accesses
llvm-svn: 211372
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ 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
|
|
|
|
|
|
|
|
|
| |
+ Added const iterator version
+ Changed name to begin/end to allow range loops
+ Changed call sites to range loops
+ Changed typename to (const_)iterator
llvm-svn: 210927
|
|
|
|
| |
llvm-svn: 210926
|
|
|
|
| |
llvm-svn: 210170
|
|
|
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, Polly edition.
If you want to know more details about this, you can see the recent
commits to Debug.h in LLVM. This is just the Polly segment of a cleanup
I'm doing globally for this macro.
llvm-svn: 206852
|
|
|
|
| |
llvm-svn: 206361
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
We update to a newer version of isl, which includes changes to the compute
out facility that make it a lot more predicable. With our new value, we can
reliably bail out for all reported bugs, while still being able to compute
dependences for all but two test cases in the LLVM test suite. For the remaining
two test cases, the dependence problem we construct is unnecessarily complex,
so there is hope we can improve on this. However, to avoid any future issues,
having a reliable compute out facility in place is important.
llvm-svn: 206106
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
llvm.org/PR19081 reports that the polly dependence analysis causes some h264
compilation to hang. We adjust the compute out, to ensure we do not block on
expensive dependence calculations.
llvm-svn: 204168
|
|
|
|
| |
llvm-svn: 204165
|
|
|
|
|
| |
Contributed-by: Sam Novak <snovak@uwsp.edu>
llvm-svn: 203869
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Reported-by: Sebastian Pop <spop@codeaurora.org>
Reported-by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 201903
|
|
|
|
| |
llvm-svn: 201898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 may revert this depending on how the current discussion on llvm-commits
ends.
llvm-svn: 198581
|
|
|
|
|
| |
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187981
|
|
|
|
|
| |
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187498
|
|
|
|
| |
llvm-svn: 186288
|
|
|
|
|
|
|
| |
We make the option a clear choice between the two analysis types and add
descriptions about the difference between the two.
llvm-svn: 186251
|
|
|
|
| |
llvm-svn: 181297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
clang-format become way more stable. This time we mainly reformat function
signatures.
llvm-svn: 181294
|
|
|
|
| |
llvm-svn: 179160
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Everything except INITIALIZE_PASS_* macros
llvm-svn: 174367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We fix the following formatting problems found by clang-format:
- 80 cols violations
- Obvious problems with missing or too many spaces
- multiple new lines in a row
clang-format suggests many more changes, most of them falling in the following
two categories:
1) clang-format does not at all format a piece of code nicely
2) The style that clang-format suggests does not match the style used in
Polly/LLVM
I consider differences caused by reason 1) bugs, which should be fixed by
improving clang-format. Differences due to 2) need to be investigated closer
to understand the cause of the difference and the solution that should be taken.
llvm-svn: 171241
|
|
|
|
|
|
|
|
|
| |
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 dependency printing was accidentally removed in during a previous
restructuring.
llvm-svn: 162662
|