This replaces the ancient INVALID/INVALID_NOVERIFY macros with a real
function.
The new invalid(..) function uses small diagnostic objects that are
generated on demand. We can store arbitrary additional information per
error type and generate useful debug/error messages on the fly.
Use it as follows:
if (/* Some error condition (ReportFoo) */)
invalid<ReportFoo>(Context, /*Assert=*/true/false,
(/* List of helpful diagnostic objects */));
Where ReportFoo is a subclass of RejectReason that is able to take the
list of helpful diagnostic objects in its constructor.
The implementation of invalid will create the report and fire
an assertion, if necessary.
llvm-svn: 205414
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
Value::user_iterator changes in LLVM r203364. Converts several of these
loops to nice range based loops in the process.
Built and tested cleanly for me, yay for being able to fully build and
test Polly changes!
llvm-svn: 203381
The module LLVMPolly.so links to that. There is really no reason to build a
large number of mini-libraries here, especially as we do have dependences
between the libraries that are not properly handled and that make linking fail
on darwin.
Submitted-by: David Fang <fang@csl.cornell.edu>
llvm-svn: 202743
We mostly iterate over read-only values. Following a suggestion by Duncan P.N
Exons Smith, we use the construct 'const auto &' for this.
llvm-svn: 202651
clang-format requires a space before the ":" in the foreach loop. Even though
this is surprising to me, we follow this style to make our formatting
consistent with clang-format. I found that this clang-format style is used in a
couple of C++11 examples, hence I believe the fact that clang-format adds a
colon is not a bug but just something I was not used to yet.
llvm-svn: 202648
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
In case the domain of a statement is empty, the schedule optimizer set by
accident the schedule to a NULL pointer. This is incorrect. Instead, we set
it to an empty isl_map with zero schedule dimensions. We already checked for
this in our test cases, but unfortunately the test cases did not fail as
expected. The assert we add in this commit now ensures that the test cases
fail properly in case we regress on this again.
llvm-svn: 201886
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
We do not have a use for this information at the moment. If we need this at some
point, the "instruction -> access" mapping needs to be enhanced as a single
instruction could then possibly perform multiple accesses.
This patch allows us to build the polyhedral information for scops with scalar
dependences.
llvm-svn: 201815
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
In rare cases, a region R which is itself not valid has an indirect child region
that is valid. When R becomes part of a valid region by expansion of another
region, then all children of R have to be erased from the set of valid regions.
This patch ensures that indirect children are erased in addition to direct
children.
Contributed-by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
Tobias: I added a reduced test case and adjusted the logic of the patch to
only recurse until the first child is found.
llvm-svn: 200411
Verification of base addresses is difficult as the independent blocks pass may
introduce aliasing that was not there during scop detection. As a midterm
solution -polly-codegen-scev will remove the need for the independent blocks
pass. For now, we do not verify at compile time that the independent blocks pass
does not make the base addresses loop invariant. Disabling this just removes
one of the multiple safety layers we have. We still can check for correctness
in our regression tests.
llvm-svn: 200315
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
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
This fixes a crash that appeared when generating dotty graphs for functions
without loops (for which we do not calculate polyhedral information).
llvm-svn: 198364
We now report the following:
$ polly-clang -O3 -mllvm -polly -mllvm -polly-report test.c -c \
-gline-tables-only
note: Polly detected an optimizable loop region (scop) in function 'foo'
test.c:2: Start of scop
test.c:3: End of scop
note: Polly detected an optimizable loop region (scop) in function 'bar'
test.c:9: Start of scop
test.c:13: End of scop
llvm-svn: 197558
Sebastian Pop