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
During code preperation trivial PHI nodes (mainly introduced by lcssa) are
deleted to decrease the number of introduced allocas (==> dependences). However
simply replacing them by their only incoming value would cause the independent
block pass to introduce new allocas. To prevent this we try to share stack slots
during code preperarion, hence to reuse a already created alloca 'to demote' the
trivial PHI node. This works if we know that the value stored in this alloca
will be the incoming value of the trivial PHI at the end of the predecessor
block of this trivial PHI.
Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 205320
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
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
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
This reverts the broken modularized build.
This builds the classic loadable module. The separation
of library and plugin is yet to be done in a future patch.
llvm-svn: 203952
to avoid build errors like this:
In file included from ../include/llvm/IR/IntrinsicInst.h:30:0,
from ../tools/polly/lib/CodeGen/BlockGenerators.cpp:28:
../include/llvm/IR/Intrinsics.h:41:34: fatal error: llvm/IR/Intrinsics.gen: No such file or directory
The earlier change in commit b1d2e6d5c3ce151ef6b7213c00019715e63d7cfb has been
accidentally reverted in:
commit 6b1963814877f5b1b161d3a73a3c8246c4ad4787
Author: simbuerg <simbuerg@91177308-0d34-0410-b5e6-96231b3b80d8>
Date: Tue Mar 11 21:26:06 2014 +0000
Refactor Polly's Pass creation and initialization.
Rename some files and adjust cmake accordingly
llvm-svn: 203843
In case we are at the innermost band, we try to prepare for vectorization. This
means, we look for the innermost parallel loop and strip mine this loop to the
innermost level using a strip-mine factor corresponding to the number of vector
iterations.
For whatever reason, the code that implemented this feature was broken. We now
added a comment, a test case and obviously also the right code.
llvm-svn: 203544
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
to avoid build errors like this:
In file included from ../include/llvm/IR/IntrinsicInst.h:30:0,
from ../tools/polly/lib/CodeGen/BlockGenerators.cpp:28:
../include/llvm/IR/Intrinsics.h:41:34: fatal error: llvm/IR/Intrinsics.gen: No such file or directory
llvm-svn: 203495
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
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
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-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
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 'obsequi' we have a scop in which the current dead code elimination works,
but the generated code is way too complex. To avoid this trouble (and to not
disable the DCE entirely) we add an additional approximative step before
the actual dead code elimination. This should fix one of the two current
nightly-test issues.
Polly could be improved to handle 'obsequi' by teaching it to introduce only a
single parameter for (%1 and zext %1) which halves the number of parameters and
allows polly to derive a simpler representation for the set of live iterations.
However, this needs some time to investigate.
I will commit a test case as soon as we have a reduced one.
llvm-svn: 202010
Sebastian Pop