For for-nodes that are translated to a set of vector lanes, we already know the
overall number of iterations. Calculating the upper bound is consequently not
necessary. This change removes the code for upper bound calculation, which was
probably copy/pasted from the code generation for the normal for-loop.
This issue was found by Sylvestre's scan-build server.
llvm-svn: 193925
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
Instead of defining the relevant functions inline, we now just keep the
declarations in the class itself. This makes the class declaration a lot
easier to read as all functions can be seen at once. We also use this
opportunity to privatize all functions not used in the public interface of the
class.
llvm-svn: 190841
Use 0 >= 1 instead of 0 != 0 to represent 'false'. This might be slightly more
efficient as isl may create a union of sets for 0 != 0, whereas this is never
needed for the expression 0 >= 1.
Contributed-by: Alexandre Isoard <alexandre.isoard@gmail.com>
llvm-svn: 190384
The Makefile rule "polly-test" has been renamed to
"check-polly" in r182171. This CL updates the document and
the automatic build script.
llvm-svn: 188624
SCoP invariant parameters with the different start value would deter parameter
sharing. For example, when compiling the following C code:
void foo(float *input) {
for (long j = 0; j < 8; j++) {
// SCoP begin
for (long i = 0; i < 8; i++) {
float x = input[j * 64 + i + 1];
input[j * 64 + i] = x * x;
}
}
}
Polly would creat two parameters for these memory accesses:
p_0: {0,+,256}
p_2: {4,+,256}
[j * 64 + i + 1] => MemRef_input[o0] : 4o0 = p_1 + 4i0
[j * 64 + i] => MemRef_input[o0] : 4o0 = p_0 + 4i0
These parameters only differ from start value. To enable parameter sharing,
we split the start value from SCEVAddRecExpr, so they would share a single
parameter that always has zero start value:
p0: {0,+,256}<%for.cond1.preheader>
[j * 64 + i + 1] => MemRef_input[o0] : 4o0 = 4 + p_1 + 4i0
[j * 64 + i] => MemRef_input[o0] : 4o0 = p_0 + 4i0
Such translation can make the polly-dependence much faster.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187728
In case we detect that the schedule the user wants to import is invalid we
refuse it _and_ free the isl_maps containing it.
Another bug found thanks to Rafael.
llvm-svn: 187339
We now use __isl_take to annotate the uses of the isl_set where we got the
memory management wrong.
Thanks to Rafael! His pipefail work hardened our test environment and exposed
this bug nicely.
llvm-svn: 187338
Tobias Grosser