CMake insists that for each target, one uses only the non-keyword
version of target_link_library
target_link_library(mytarget lib)
or the one with PUBLIC/PRIVATE/INTERFACE keyword:
target_link_library(mytarget PUBLIC lib)
Otherwise, CMake fails with the error message:
The keyword signature for target_link_libraries has already been used with
the target "mytarget". All uses of target_link_libraries with a target
must be either all-keyword or all-plain.
Change all occurances of target_link_library to the newer keyworded
version to avoid such errors. Some already have been changed in r319840,
but might not be sufficient for all build configurations to build
the doxygen manual.
Reported-by: Tanya Lattner <tanyalattner@llvm.org>
llvm-svn: 322376
We add a ScopInliner pass which inlines functions based on a simple heuristic:
Let `g` call `f`.
If we can model all of `f` as a Scop, we inline `f` into `g`.
This requires `-polly-detect-full-function` to be enabled. So, the pass
asserts that `-polly-detect-full-function` is enabled.
Differential Revision: https://reviews.llvm.org/D36832
llvm-svn: 311126
Summary:
This pass detangles induction variables from functions, which take variables by
reference. Most fortran functions compiled with gfortran pass variables by
reference. Unfortunately a common pattern, printf calls of induction variables,
prevent in this situation the promotion of the induction variable to a register,
which again inhibits any kind of loop analysis. To work around this issue
we developed a specialized pass which introduces separate alloca slots for
known-read-only references, which indicate the mem2reg pass that the induction
variables can be promoted to registers and consquently enable SCEV to work.
We currently hardcode the information that a function
_gfortran_transfer_integer_write does not read its second parameter, as
dragonegg does not add the right annotations and we cannot change old dragonegg
releases. Hopefully flang will produce the right annotations.
Reviewers: Meinersbur, bollu, singam-sanjay
Reviewed By: bollu
Subscribers: mgorny, pollydev, llvm-commits
Tags: #polly
Differential Revision: https://reviews.llvm.org/D36800
llvm-svn: 311066
This pass is useful to automatically convert a codebase that uses malloc/free
to use their managed memory counterparts.
Currently, rewrite malloc and free to the `polly_{malloc,free}Managed` variants.
A future patch will teach ManagedMemoryRewrite to rewrite global arrays
as pointers to globally allocated managed memory.
Differential Revision: https://reviews.llvm.org/D36513
llvm-svn: 310471
This commit implements the initial version of fully-indexed static
expansion.
```
for(int i = 0; i<Ni; i++)
for(int j = 0; j<Ni; j++)
S: B[j] = j;
T: A[i] = B[i]
```
After the pass, we want this :
```
for(int i = 0; i<Ni; i++)
for(int j = 0; j<Ni; j++)
S: B[i][j] = j;
T: A[i] = B[i][i]
```
For now we bail (fail) in the following cases:
- Scalar access
- Multiple writes per SAI
- MayWrite Access
- Expansion that leads to an access to the original array
Furthermore: We still miss checks for escaping references to the array
base pointers. A future commit will add the missing escape-checks to
stay correct in those cases. The expansion is still locked behind a
CLI-Option and should not yet be used.
Patch contributed by: Nicholas Bonfante <bonfante.nicolas@gmail.com>
Reviewers: simbuerg, Meinersbur, bollu
Reviewed By: Meinersbur
Subscribers: mgorny, llvm-commits, pollydev
Differential Revision: https://reviews.llvm.org/D34982
llvm-svn: 310304
Summary:
This allows us to map functions such as exp, expf, expl, for which no
LLVM intrinsics exist. Instead, we link to NVIDIA's libdevice which provides
high-performance implementations of a wide range of (math) functions. We
currently link only a small subset, the exp, cos and copysign functions. Other
functions will be enabled as needed.
Reviewers: bollu, singam-sanjay
Reviewed By: bollu
Subscribers: tstellar, tra, nemanjai, pollydev, mgorny, llvm-commits, kbarton
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35703
llvm-svn: 309560
This pass 'forwards' operand trees into statements that use them in
order to avoid scalar dependencies.
This minimal implementation handles only the case of speculatable
instructions. We will successively add support for:
- Hoisted loads
- Read-only values
- Synthesizable values
- Loads
- PHIs
- Forwarding only parts of the tree
Differential Revision: https://reviews.llvm.org/D35754
llvm-svn: 308825
Summary:
As of now, Polly uses llvm-config to set up LLVM dependencies in an out-of-tree build.
This is problematic for two reasons:
1) Right now, in-tree and out-of-tree builds in fact do different things. E.g., in an in-tree build, libPolly depends on a handful of LLVM libraries, while in an out-of-tree build it depends on all of them. This means that we often need to treat both paths seperately.
2) I'm specifically unhappy with the way libPolly is linked right now, because it just blindly links against all the LLVM libs. That doesn't make a lot of sense. For instance, one of these libs is LLVMTableGen, which contains a command line definition of a -o option. This means that I can not link an out-of-tree libPolly into a tool which might want to offer a -o option as well.
This patch (mostly) drop the use of llvm-config in favor of LLVMs exported cmake package. However, building Polly with unittests requires access to the gtest sources (in the LLVM source tree). If we're building against an LLVM installation, this source tree is unavailable and must specified. I'm using llvm-config to provide a default in this case.
Reviewers: Meinersbur, grosser
Reviewed By: grosser
Subscribers: tstellar, bollu, chapuni, mgorny, pollydev, llvm-commits
Differential Revision: https://reviews.llvm.org/D33299
llvm-svn: 307650
Allow using a system's install jsoncpp library instead of the bundled
one with the setting POLLY_BUNDLED_JSONCPP=OFF.
This fixes llvm.org/PR32929
Differential Revision: https://reviews.llvm.org/D32922
llvm-svn: 302336
If a ScopStmt references a (scalar) value, there are multiple
possibilities where this value can come. The decision about what kind of
use it is must be handled consistently at different places, which can be
error-prone. VirtualUse is meant to centralize the handling of the
different types of value uses.
This patch makes ScopBuilder and CodeGeneration use VirtualUse. This
already helps to show inconsistencies with the value handling. In order
to keep this patch NFC, exceptions to the general rules are added.
These might be fixed later if they turn to problems. Overall, this
should result in fewer post-codegen IR-verification errors, but instead
assertion failures in `getNewValue` that are closer to the actual error.
Differential Revision: https://reviews.llvm.org/D32667
llvm-svn: 302157
Polly comes in two library flavors: One loadable module to use the
LLVM framework -load mechanism, and another one that host applications
can link to. These have very different requirements for Polly's
own dependencies.
The loadable module assumes that all its LLVM dependencies are already
available in the address space of the host application, and is not allowed
to bring in its own copy of any LLVM library (including the NVPTX
backend in case of Polly-ACC).
The non-module library is intended to be linked to using
target_link_libraries. CMake would then resolve all of its dependencies,
including NVPTX and ensure that only a single instance of each library
will be used.
Differential Revision: https://reviews.llvm.org/D32442
llvm-svn: 301558
Add support for -polly-codegen-perf-monitoring. When performance monitoring
is enabled, we emit performance monitoring code during code generation that
prints after program exit statistics about the total number of cycles executed
as well as the number of cycles spent in scops. This gives an estimate on how
useful polyhedral optimizations might be for a given program.
Example output:
Polly runtime information
-------------------------
Total: 783110081637
Scops: 663718949365
In the future, we might also add functionality to measure how much time is spent
in optimized scops and how many cycles are spent in the fallback code.
Reviewers: bollu,sebpop
Tags: #polly
Differential Revision: https://reviews.llvm.org/D31599
llvm-svn: 299359
ScopInfo's normal profitability heuristic considers SCoPs where all
statements have scalar writes as not profitably optimizable and
invalidate the SCoP in that case. However, -polly-delicm and
-polly-simplify may be able to remove some of the scalar writes such
that the flag -polly-unprofitable-scalar-accs=false allows disabling
that part of the heuristic.
In cases where DeLICM (or other passes after ScopInfo) are not
successful in removing scalar writes, the SCoP is still not profitably
optimizable. The schedule optimizer would again try computing another
schedule, resulting in slower compilation.
The -polly-prune-unprofitable pass applies the profitability heuristic
again before the schedule optimizer Polly can still bail out even with
-polly-unprofitable-scalar-accs=false.
Differential Revision: https://reviews.llvm.org/D31033
llvm-svn: 298080
This new pass removes unnecessary accesses and writes. It currently
supports 2 simplifications, but more are planned.
It removes write accesses that write a loaded value back to the location
it was loaded from. It is a typical artifact from DeLICM. Removing it
will get rid of bogus dependencies later in dependency analysis.
It also removes statements without side-effects. ScopInfo already
removes these, but the removal of unnecessary writes can result in
more side-effect free statements.
Differential Revision: https://reviews.llvm.org/D30820
llvm-svn: 297473
This pass allows writing the LLVM-IR just before and after the Polly
passes to a file.
Dumping the IR before Polly helps reproducing bugs that occur in code
generated by clang. It is the only reliable way to get the IR that
triggers a bug. The alternative is to emit the IR with
clang -c -emit-llvm -S -o dump.ll
then pass it through all optimization passes
opt dump.ll -basicaa -sroa ... -S -o optdump.ll
to then reproduce the error with
opt optdump.ll -polly-opt-isl -polly-codegen -analyze
However, the IR is not the same. -O3 uses a PassBuilder than creates passes
with different parameters than the default.
Dumping the IR after Polly is useful to compare a miscompilation with
a known-good configuration.
Differential Revision: https://reviews.llvm.org/D30788
llvm-svn: 297415
This patch adds an option to build against a version of libisl already
installed on the system. The installation is autodetected using the
pkg-config file shipped with isl.
The detection of the library is in the FindISL.cmake module that creates
an imported target.
Contributed-by: Philip Pfaffe <philip.pfaffe@gmail.com>
Differential Revision: https://reviews.llvm.org/D30043
llvm-svn: 296361
Add some generally useful isl tools into a their own new ISLTools.cpp.
These are the helpers were extracted from and will be use by the DeLICM
algorithm (https://reviews.llvm.org/D24716).
Suggested-by: Tobias Grosser <tobias@grosser.es>
llvm-svn: 293340
Add an empty DeLICM pass, without any functional parts.
Extracting the boilerplate from the the functional part reduces the size of the
code to review (https://reviews.llvm.org/D24716)
Suggested-by: Tobias Grosser <tobias@grosser.es>
llvm-svn: 288160
The -polly-flatten-schedule pass reduces the number of scattering
dimensions in its isl_union_map form to make them easier to understand.
It is not meant to be used in production, only for debugging and
regression tests.
To illustrate, how it can make sets simpler, here is a lifetime set
used computed by the porposed DeLICM pass without flattening:
{ Stmt_reduction_for[0, 4] -> [0, 2, o2, o3] : o2 < 0;
Stmt_reduction_for[0, 4] -> [0, 1, o2, o3] : o2 >= 5;
Stmt_reduction_for[0, 4] -> [0, 1, 4, o3] : o3 > 0;
Stmt_reduction_for[0, i1] -> [0, 1, i1, 1] : 0 <= i1 <= 3;
Stmt_reduction_for[0, 4] -> [0, 2, 0, o3] : o3 <= 0 }
And here the same lifetime for a semantically identical one-dimensional
schedule:
{ Stmt_reduction_for[0, i1] -> [2 + 3i1] : 0 <= i1 <= 4 }
Differential Revision: https://reviews.llvm.org/D24310
llvm-svn: 280948
Adding a new pass PolyhedralInfo. This pass will be the interface to Polly.
Initially, we will provide the following interface:
- #IsParallel(Loop *L) - return a bool depending on whether the loop is
parallel or not for the given program order.
Patch by Utpal Bora <cs14mtech11017@iith.ac.in>
Differential Revision: https://reviews.llvm.org/D21486
llvm-svn: 276637
Add a new pass to serve as basis for automatic accelerator mapping in Polly.
The pass structure and the analyses preserved are copied from
CodeGeneration.cpp, as we will rely on IslNodeBuilder and IslExprBuilder for
LLVM-IR code generation.
Polly's accelerator code generation is enabled with -polly-target=gpu
I would like to use this commit as opportunity to thank Yabin Hu for his work in
the context of two Google summer of code projects during which he implemented
initial prototypes of the Polly accelerator code generation -- in parts this
code is already available in todays Polly (e.g., tools/GPURuntime). More will
come as part of the upcoming Polly ACC changes.
Reviewers: Meinersbur
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D22036
llvm-svn: 275275
ppcg will be used to provide mapping decisions for GPU code generation.
As we do not use C as input language, we do not include pet. However, we include
pet.h from pet 82cacb71 plus a set of dummy functions to ensure ppcg links
without problems.
The version of ppcg committed is unmodified ppcg-0.04 which has been well tested
in the context of LLVM. It does not provide an official library interface yet,
which means that in upcoming commits we will add minor modifications to make
necessary functionality accessible. We will aim to upstream these modifications
after we gained enough experience with GPU generation support in Polly to
propose a stable interface.
Reviewers: Meinersbur
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D22033
llvm-svn: 275274
The methods in ScopBuilder are used for the construction of a Scop,
while the remaining classes of ScopInfo are required by all passes that
use Polly's polyhedral analysis.
llvm-svn: 273982
darwin requires the additional linkages of...
LLVMBitReader
LLVMMCParser
LLVMObject
LLVMProfileData
LLVMTarget
LLVMVectorize
as the darwin requires all of the weak undefined symbols in a library to be
resolved when linking it against an executable (unless
-Wl,-undefined,dynamic_lookup is used to override the default behavior of
-Wl,-undefined,error).
Contributed-by: Jack Howarth
llvm-svn: 259332
Re-run canonicalization passes after Polly's code generation.
The set of passes currently added here are nearly all the passes between
--polly-position=early and --polly-position=before-vectorizer, i.e. all
passes that would usually run after Polly.
In order to run these only if Polly actually modified the code, we add a
function attribute "polly-optimzed" to a function that contains
generated code. The cleanup pass is skipped if the function does not
have this attribute.
There is no support by the (legacy) PassManager to run passes only under
some conditions. One could have wrapped all transformation passes to run
only when CodeGeneration changed the code, but the analyses would run
anyway. This patch creates an independent pass manager. The
disadvantages are that all analyses have to re-run even if preserved and
it does not honor compiler switches like the PassManagerBuilder does.
Differential Revision: http://reviews.llvm.org/D14333
llvm-svn: 254150
Polly can now be used as a analysis only tool as long as the code
generation is disabled. However, we do not have an alternative to the
independent blocks pass in place yet, though in the relevant cases
this does not seem to impact the performance much. Nevertheless, a
virtual alternative that allows the same transformations without
changing the input region will follow shortly.
llvm-svn: 250652
Refactor all ISL-related cmake build instructions into its own
CMakeLists.txt and build as a separate library.
This is useful to apply ISL-related build flags to ISL only and not to
Polly's files. Also, it the separation of both projects becomes clearer.
Proposed name of the library is Polly_isl. It is not "isl" to avoid
mix-up with potentially installed libisl.{a|so}.
Tested configurations:
- Windows with cmake 3.2
- Ubuntu with cmake 3.0.2
- Ubuntu with cmake 3.0.2 BUILD_SHARED_LIBS on
- Ubuntu with cmake 2.8.12.2 (LLVM minimum version)
- Ubuntu out-of-LLVM-tree
Differential Revision: http://reviews.llvm.org/D12810
llvm-svn: 248484
This prepares for a series of patches that merges TempScopInfo into ScopInfo to
reduce Polly's code complexity. Only ScopInfo.{cpp|h} will be left thereafter.
Moving the code of TempScopInfo in one commit makes the mains diffs simpler to
understand.
In detail, merging the following classes is planned:
TempScopInfo into ScopInfo
TempScop into Scop
IRAccess into MemoryAccess
Only moving code, no functional changes intended.
Differential Version: http://reviews.llvm.org/D12693
llvm-svn: 247274
This change has three major advantages:
- The ScopInfo becomes smaller.
- It allows to use the SCEVAffinator from outside the ScopInfo.
- A member object allows state which in turn allows e.g., caching.
Differential Revision: http://reviews.llvm.org/D9099
llvm-svn: 244730
Put all Polly targets into a single "Polly" category (i.e.
solution folder). Previously there was no recognizable scheme and most
categories contained just one or two targets or targets didn't belong
to any category.
Reviewers: grosser
llvm-svn: 242779
Query the isl_config.h macros recently added to ISL. One of it looks for
the ffs (find first set), whose functionality is available in Visual
Studio with _BitScanForward. Also add isl_ffs.c to the source files
which contains the implementation of ffs using _BitScanForward.
Reviewers: grosser
llvm-svn: 242770
Summary:
With small integer optimization (short: sio) enabled, ISL uses 32 bit
integers for its arithmetic and only falls back to a big integer library
(in the case of Polly: IMath) if an operation's result is too large.
This gives a massive performance boost for most application using ISL.
For instance, experiments with ppcg (polyhedral source-to-source
compiler) show speed-ups of 5.8 (compared to plain IMath), respectively
2.7 (compared to GMP).
In Polly, a smaller fraction of the total compile time is taken by ISL,
but the speed-ups are still very significant. The buildbots measure
compilation speed-up up to 1.8 (oourafft, floyd-warshall, symm). All
Polybench benchmarks compile in at least 9% less time, and about 20%
less on average.
Detailed Polybench compile time results (median of 10):
correlation -25.51%
covariance -24.82%
2mm -26.64%
3mm -28.69%
atax -13.70%
bicg -10.78%
cholesky -40.67%
doitgen -11.60%
gemm -11.54%
gemver -10.63%
gesummv -11.54%
mvt -9.43%
symm -41.25%
syr2k -14.71%
syrk -14.52%
trisolv -17.65%
trmm -9.78%
durbin -19.32%
dynprog -9.09%
gramschmidt -15.38%
lu -21.77%
floyd-warshall -42.71%
reg_detect -41.17%
adi -36.69%
fdtd-2d -32.61%
fdtd-apml -21.90%
jacobi-1d-imper -9.41%
jacobi-2d-imper -27.65%
seidel-2d -31.00%
Reviewers: grosser
Reviewed By: grosser
Subscribers: Meinersbur, llvm-commits, pollydev
Projects: #polly
Differential Revision: http://reviews.llvm.org/D10506
llvm-svn: 240689
There were two issues:
* ISL's configure generates include/isl/stdint.h, not isl/stdint.h as
assumed. This is also changed in the CMake build.
* Need to pass --with-int=imath to ISL's configure; the default is gmp.
Polly's configure has been regenerated due to changing configure.ac
llvm-svn: 240657
ISL with small integer optimization requires C99 to compile. gcc < 5.0
still uses C89 as default, so we need to enable the options to compile
in C99 mode.
This patch is preparing the actual activation of small integer
optimization.
Differential version: http://reviews.llvm.org/D10610
Reviewers: grosser
llvm-svn: 240322
ISL's ./configure examines the system for the stdint.h to include and
creates a header file that points to it. On C99-compatible system
#include <stdint.h>
is always valid such there no need for system introspection. This should
unbreak the build bots.
llvm-svn: 240315
Currently the Polly repository contains the ISL sources with bogus
isl_config.h and gitversion.h. This is problematic. In this state a
macro
#define __attribute__(x)
becomes active in the source, leading to various problems e.g. when
included before system header files. This patch will instead generate
the two files specific to the host system at configure-time.
For CMake, we replicate the tests that ISL's configure performs using
try_compile(). In autotools build, we just invoke ISL's configure to
generate the two files. This consequently required regenerating
autoconf/configure.
'make dist' distributions of ISL contain a file GIT_HEAD_ID which
contains the version the distribution is derived from. The repository
files themselves do not contain such a hint. In a later commit we will
replace the isl directory by the contents of such a .tar.gz. It does
not contain the files imdrover.c iprime.c pi.c and rsamath.c currently
compiled into Polly, but not used and therefore are removed by this
patch.
In the long term we plan to generate a dedicated library for ISL instead
of adding its files to Polly.
This also does not yet include the switch to small-integer optimized ISL
nor enabling C99 mode required for the former. Those will come as well
in separate patches.
Differential version: http://reviews.llvm.org/D10603
Reviewers: grosser
llvm-svn: 240301
This code has been part of Polly's GPGPU backend, which has been remove together
with the code generation backend. Development now continues in an out-of-tree
branch.
llvm-svn: 237450
Besides class, function and file names, we also change the command line option
from -polly-codegen-isl to just -polly-codegen. The isl postfix is a leftover
from the times when we still had the CLooG based -polly-codegen. Today it is
just redundant and we drop it.
llvm-svn: 237099
Michael Kruse