This has shown better results for 2mm, 3mm and a couple of other benchmarks.
After this we show consistenly better results as PoCC with maxfuse. We need
to see if PoCC can also give better results with another fusion strategy.
llvm-svn: 149267
maximise_band_depth does not seem to have any effect for now, but it may help to
increase the amount of tileable loops. We expose the flag to be able to analyze
its effects when looking into individual benchmarks.
llvm-svn: 149266
This speeds up the scheduler by orders of magnitude and in addition yields often
to a better schedule.
With this we can compile all polybench kernels with less than 5x compile time
overhead. In general the overhead is even less than 2-3x. This is still with
running a lot of redundant passes and no compile time tuning at all. There are
several obvious areas where we can improve here further.
There are also two test cases where we cannot find a schedule any more (cholesky
and another). I will look into them later on.
With this we have a very solid base line from which we can start to optimize
further.
llvm-svn: 149263
In case we can not analyze an access function, we do not discard the SCoP, but
assume conservatively that all memory accesses that can be derived from our base
pointer may be accessed.
Patch provided by: Marcello Maggioni <hayarms@gmail.com>
llvm-svn: 146972
To extract a preoptimized LLVM-IR file from a C-file run:
clang -Xclang -load -Xclang LLVMPolly.so -O0 -mllvm -polly file.c -S -emit-llvm
On the generated file you can directly run passes such as:
'opt -view-scops file.s'
llvm-svn: 146560
Previously the scheduler was splitting bands at the level at which it detected
that the splitting of the band is necessary. This may introduce an additional
level of bands, that can be avoided by backtracking and splitting on a higher
level. Additional splits reduce the number of loops that can be tiled, such that
avoiding splits and maximizing the band depth seems preferable.
As a first data point we looked at 2mm and 3mm from the polybench test suite.
For both maximizing the tilable bands results in a significant (5-10x)
performance improvement.
This patch enables the isl scheduler option to maximize the band depth.
llvm-svn: 146557
If larger coefficients appear as part of the input dependences, the schedule
calculation can take a very long time. We observed that the main overhead in
this calculation is due to optimizing the constant coefficients. They are
misused to increase locality by merging several unrelated dimensions into a
single dimension. This unwanted optimization increases the complexity of the
generated code and furthermore slows it down.
We use a new isl scheduler option to bound the values in the constant dimension
by a user defined value (20 in our case). If the right value is choosen, costly
overoptimization is prevented.
This solution works, but requires a specific (here almost randomly choosen)
value by which the constants are bound. For the moment, this is our best
solution, but we hope to to find a more generic one later on.
After these patch the extremly long compile time for simple kernels like 2mm or
3mm is reduced to a reasonable amount of time (Not more than a couple of seconds
even in debug mode).
llvm-svn: 146556
We forgot to include the unistd.h header file that defines the
functions mentioned above. This was not a problem with gnu C++ library,
however it did not work for libc++.
llvm-svn: 145790
We disable Polly by default and add a new option '-polly' that enables Polly.
This allows us to create an the alias
$ alias clang clang -Xclang -load -Xclang LLVMPolly.so
which loads Polly always into clang. It can now be enabled by running:
$ clang -O3 -mllvm -polly file.c
To enable it by default an alias pollycc can be create
$ alias pollycc clang -O3 -mllvm -polly
llvm-svn: 144917
- Use uppercase letters according to the LLVM coding style
- Rename functions to not include 'tiledSchedule', but just Schedule. This
is more correct as tiling might be disabled.
llvm-svn: 144899
The new isl_id support for parmeters created problems when importing new
access functions. Even though the parameters had the same names,
they were mapped to different ids and where therefore incompatible.
We copy the ids now from the old parameter dimensions. This fixes the
problem.
llvm-svn: 144642
Parameters can be complex SCEV expressions, but they can also be single scalar
values. If a parameters is such a simple scalar value and the value is named,
use this name to name the isl parameter dimensions.
llvm-svn: 144641
This does not work reliable and is probably not needed. I accidentally changed
this in this recent commit:
commit a0bcd63c6ffa81616cf8c6663a87588803f7d91c
Author: grosser <grosser@91177308-0d34-0410-b5e6-96231b3b80d8>
Date: Thu Nov 10 12:47:21 2011 +0000
ScopDetect: Use INVALID macro to fail in case of aliasing
This simplifies the code and also makes the error message available to the
graphviz scop viewer.
git-svn-id: https://llvm.org/svn/llvm-project/polly/trunk@144284
llvm-svn: 144286
address is part of the access function. Also remove unused special cases that
were necessery when the base address was still contained in the access function
llvm-svn: 144280
Previously we allowed in access functions only a single SCEVUnknown, which later
became the base address. We now use getPointerBase() to derive the base address
and all remaining unknowns are handled as parameters. This allows us to handle
cases like A[b+c];
llvm-svn: 144278
This check was necessary because of the use AffineSCEVIterator in TempScopInfo.
As we removed this use recently it is not necessary any more.
llvm-svn: 144228
Tobias Grosser