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
+ 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
The functions isParallel, isInnermostParallel and IsOutermostParallel in
IslAstInfo will now return true even in the presence of broken reductions.
To compensate for this change the negated result of isReductionParallel can
be used.
llvm-svn: 214488
+ 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
Whe we build the IslAst we visit for nodes (in pre and post order) as well as
user/domain nodes. As these two sets are non overlapping we do not need to
check if we annotated a node earlier when we visit it.
llvm-svn: 214170
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
+ 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
This pulls in a couple of minor cleanups in isl. More importantly, in
preparation of the upcoming LLVM releases this change brings us back on a
released version of isl.
llvm-svn: 213062
+ 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
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
Tobias Grosser