The July issue of TOPLAS contains a 50 page discussion of the AST generation
techniques used in Polly. This discussion gives not only an in-depth
description of how we (re)generate an imperative AST from our polyhedral based
mathematical program description, but also gives interesting insights about:
- Schedule trees: A tree-based mathematical program description that enables us
to perform loop transformations on an abstract level, while issues like the
generation of the correct loop structure and loop bounds will be taken care of
by our AST generator.
- Polyhedral unrolling: We discuss techniques that allow the unrolling of
non-trivial loops in the context of parameteric loop bounds, complex tile
shapes and conditionally executed statements. Such unrolling support enables
the generation of predicated code e.g. in the context of GPGPU computing.
- Isolation for full/partial tile separation: We discuss native support for
handling full/partial tile separation and -- in general -- native support for
isolation of boundary cases to enable smooth code generation for core
computations.
- AST generation with modulo constraints: We discuss how modulo mappings are
lowered to efficient C/LLVM code.
- User-defined constraint sets for run-time checks We discuss how arbitrary
sets of constraints can be used to automatically create run-time checks that
ensure a set of constrainst actually hold. This feature is very useful to
verify at run-time various assumptions that have been taken program
optimization.
Polyhedral AST generation is more than scanning polyhedra
Tobias Grosser, Sven Verdoolaege, Albert Cohen
ACM Transations on Programming Languages and Systems (TOPLAS), 37(4), July 2015
llvm-svn: 245157
In Polly we used both the term 'scattering' and the term 'schedule' to describe
the execution order of a statement without actually distinguishing between them.
We now uniformly use the term 'schedule' for the execution order. This
corresponds to the terminology of isl.
History: CLooG introduced the term scattering as the generated code can be used
as a sequential execution order (schedule) or as a parallel dimension
enumerating different threads of execution (placement). In Polly and/or isl the
term placement was never used, but we uniformly refer to an execution order as a
schedule and only later introduce parallelism. When doing so we do not talk
about about specific placement dimensions.
llvm-svn: 235380
We do not have buildbots or anything that tests this functionality, hence it
most likely bitrots. People interested to use this functionality can always
recover it from svn history.
llvm-svn: 233570
This would add another library dependency to Polly. In many cases the
JSCoP interface we have should be enough and an external JSCoP <> OpenSCoP
converter could be written. We can reconsider this if new use cases show up.
llvm-svn: 225390
We should reconsider this after having switched to imath (instead of gmp)
as the default isl backend, as this would allow us to keep a copy of isl
in the polly svn and to consequently make it easier to distribute Polly.
llvm-svn: 225262
This commit drops the Cloog support for Polly. The scripts and
documentation are changed to only use isl as prerequisity. In the code
all Cloog specific parts have been removed and all relevant tests have
been ported to the isl backend when it was created.
llvm-svn: 223141
Arcanist (arc) will now always run linters before uploading any new
commit to Phabricator. All errors/warnings (or their absence) will be
shown in the web interface together with a explanation by the commiter
(arcanist will ask the commiter if the build was not clean).
The linters include:
- clang-format
- spelling check
- permissions check (aka. chmod)
- filename check
- merge conflict marker check
Note, that their scope is sometimes limited (see .arclint for
details).
This commit also fixes all errors and warnings these linters reported,
namely:
- spelling mistakes and typos
- executable permissions for various text files
Differential Revision: http://reviews.llvm.org/D4916
llvm-svn: 215871
Remove the PoCC and ScopLib support from Polly as we do not have a
user/maintainer for it.
Differential Revision: http://reviews.llvm.org/D4871
llvm-svn: 215563
We only supported a very old version of OpenScop that was entirely different
to what OpenScop is today. To not confuse people, we remove this old and
unusable support. If anyone is interested to add OpenScop support back in,
the relevant patches are available in version control.
llvm-svn: 206026
Reversed the order in which LD_LIBRARY_PATH is defined in order to make sure the
${CLOOG_INSTALL} prefix is found first.
Contributed-by: Christian Bielert <cib123@googlemail.com>
llvm-svn: 205556
It does not seem to add a lot of value, as it leaves unclear which parts are
mature and whichs not. Adding this informatin also does not make sense, as it
changes rapidly.
llvm-svn: 204447
This ModulePass schedules the set of Polly canonicalization passes. It is a
debugging tool that can be used to preoptimize .ll files for Polly processing.
llvm-svn: 198376
Further:
o ensure that the header is properly readable even on smaller screen sizes.
o Shorten the table of contents of the documentation section.
llvm-svn: 197794
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
It was initially committed to allow people to get a list of the files used
or generated in the matmul tutorial. Since the documentation does now
point people to the directory in their git checkout, it is not necessary anymore
to make a directory listing available. Especially, as this never worked and
recently the LLVM web server does not deliver files in this directory at all
due to the unsupported .htaccess file.
llvm-svn: 182370
As the namings of the scops have changed, polly was not able to read in the user
given .jscop files. By renaming the provided files, polly now finds them again
and can use them to optimize the matmul function. We also update the generated
files to reflect the very latest version of Polly.
llvm-svn: 182265
We now support regions with multiple entries and multiple exits natively.
Regions are not needed to be simplified to single entry and single exit.
We need to XFAIL two test cases as this change increases the scop coverage
and uncoveres two failures in the independent blocks pass. The first failure
will be fixed in a subsequent commit, the second one is in the non-default
-polly-codegen-scev mode and still needs to be fixed.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179673
Tobias Grosser