The IndVarSimplify pass in Polly uses the intrinsics header. We need to ensure
that the header is generated, before we use it. This patch fixes the problem
for the cmake build (it did not show up in the autoconf one).
Contributed by: Sameer Sahasrabuddhe <sameer.sahasrabuddhe@amd.com>
llvm-svn: 163130
This includes:
- The isl_id of the domain of the scattering must be copied from the original
domain
- Remove outdated references to a 'FinalRead' statement
- Print of the Pocc output, if -debug is provided.
- Add line breaks to some error messages.
Reported and Debugged by: Dustin Feld <d3.feld@gmail.com>
llvm-svn: 162901
Translate the selected parallel loop body into a ptx string and run it with the
cuda driver API. We limit this preliminary implementation to target the
following special test cases:
- Support only 2-dimensional parallel loops with or without only one innermost
non-parallel loop.
- Support write memory access to only one array in a SCoP.
The patch was committed with smaller changes to the build system:
There is now a flag to enable gpu code generation explictly. This was required
as we need the llvm.codegen() patch applied on the llvm sources, to compile this
feature correctly. Also, enabling gpu code generation does not require cuda.
This requirement was removed to allow 'make polly-test' runs, even without an
installed cuda runtime.
Contributed by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 161239
The Apple linker fails by default, if some function calls can not be resolved at
link time. However, all functions that are part of LLVM itself will not be
linked into Polly, but will be provided by the compiler that Polly is loaded
into. Hence, during linking we need to ignore failures due to unresolved
function calls.
llvm-svn: 161234
Cast instruction do not have side effects and can consequently be part of a
scop. We special cased them earlier, as they may be problematic within array
subscripts or loop bounds. However, the scalar evolution validator already
checks for them such that there is no need to also check the instructions within
the basic blocks. Checking them is actually overly conservative as the precence
of casts may invalidate a scop, even though scalar evolution is not influenced
by it.
llvm-svn: 160261
I did not take into account, that this patch fails to compile without the
llvm.codegen patch applied. This breaks buildbots.
I revert this until we found a solution to commit this without buildbots
complaining.
This reverts commit cb43ab80e94434e780a66be3b9a6ad466822fe33.
llvm-svn: 160165
Translate the selected parallel loop body into a ptx string and run it
with cuda driver API. We limit this preliminary implementation to
target the following special test cases:
- Support only 2-dimensional parallel loops with or without only one
innermost non-parallel loop.
- Support write memory access to only one array in a SCoP.
Contributed by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 160164
CLooG and the CLooG based code generation does not yet correctly derive the
types of the expressions, but just uses i64 for everything. This is incorrect,
but works normally pretty well. However, the recent change of adding parameter
bounds to the context made CLooG generate expressions that contain a lot of very
large integers that possibly don't fit into an i64. This broke the code
generation for several benchmarks.
To get the CLooG based code generation working again, we just don't take into
account any constraints in the context. This brings us back to the theoretical
incorrect, but in practice generally correct code.
The next step will be the isl based code generation. Here we will derive
automatically correct types.
llvm-svn: 158015
Store a pointer to each ScopStmt in the isl_id associated with the space of its
domain. This will later allow us to recover the statement during code
generation with isl.
llvm-svn: 157607
Derive the maximal and minimal values of a parameter from the type it has. Add
this information to the scop context. This information is needed, to derive
optimal types during code generation.
llvm-svn: 157245
There is no need for special code to handle SCEVUnknowns. SCEVUnkowns are always
parameters and will be handled by the generic parameter handling code in
visit().
llvm-svn: 157243
This is an incomplete implementation of the SCEV based code generation.
When finished it will remove the need for -indvars -enable-iv-rewrite.
For the moment it is still disabled. Even though it passes 'make polly-test',
there are still loose ends especially in respect of OpenMP code generation.
llvm-svn: 155717
This fixes two crashes that appeared in case of:
- A load of a non vectorizable type (e.g. float**)
- An instruction that is not vectorizable (e.g. call)
llvm-svn: 154586
Grouped unrolling means that we unroll a loop such that the different instances
of a certain statement are scheduled right after each other, but we do
not generate any vector code. The idea here is that we can schedule the
bb vectorizer right afterwards and use it heuristics to decide when
vectorization should be performed.
llvm-svn: 154251
To avoid overflows we still use a larger type (i64) while calculating the value
of the old ivs. However, we truncate the result to the type of the old iv when
providing it to the new code.
A corresponding test case is added to the polly test suite. Also, a failing test
case is fixed.
This fixes PR12311.
Contributed by: Tsingray Liu <tsingrayliu@gmail.com>
llvm-svn: 153952
When deriving new values for the statements of a SCoP, we assumed that parameter
values are constant within the SCoP and consquently do not need to be rewritten.
For OpenMP code generation this assumption is wrong, as such values are not
available in the OpenMP subfunction and consequently also may need to be
rewritten.
Committed with some changes.
Contributed-By: Johannes Doerfert <s9jodoer@stud.uni-saarland.de>
llvm-svn: 153838
We create a new file LoopGenerators that provides utility classes for the
generation of OpenMP parallel and scalar loops. This means we move a lot
of the OpenMP generation out of the Polly specific code generator.
llvm-svn: 153325
This also adds support for modifiable write accesses (until now only read
accesses where supported). We currently do not derive an exact type for the
expression, but assume that i64 is good enough. This will be improved in future
patches.
Contributed by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 153319
This functionality is not available in LLVM trunk and breaks the compilation of
Polly. This patch fixes the compilation, but may not be enough to recover all
functionality.
llvm-svn: 153318
For boolean flags in Polly there is no problem if they are given more than once.
Hence, we can allow it to not fail for build systems that (acciently) add flags
several times.
This fixes: PR12278
Reported by: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152933
We currently do not support pointer types in affine expressions. Hence, we
disallow in the SCoP detection. Later we may decide to add support for them.
This fixes PR12277
Reported-By: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152928
This also fixes UMax where we did not correctly keep track of the parameters.
Fixes PR12275.
Reported-By: Sebastian Pop <sebpop@gmail.com>
llvm-svn: 152913
The FinalRead statement represented a virtual read that is executed after the
SCoP. It was used when we verified the correctness of a schedule by checking if
it yields the same FLOW dependences as the original code. This is only works, if
we have a final read that reads all memory at the end of the SCoP.
We now switched to just checking if a schedule does not introduce negative
dependences and also consider WAW WAR dependences. This restricts the schedules
a little bit more, but we do not have any optimizer that would calculate a more
complex schedule. Hence, for now final reads are obsolete.
llvm-svn: 152319
We now just check if the new scattering would create non-positive dependences.
This is a lot faster than recalculating dependences (which is especially slow
on tiled code).
llvm-svn: 152230
This change itself should not change functionality, but it will make it easier
to support use different dependence kinds in for validity and proximity
constraints.
llvm-svn: 150483
This allows us to enable -enable-iv-rewrite by default and releases LLVM from
the burdon to keep that feature. This is an intermediate step. We plan to soon
remove the need for rewritten induction variables entirely.
llvm-svn: 150481
When I first tried to commit this patch, the builder pointed after generation
of a loop still into the loop body. This means that code that was supposed to
be generated after the loop was generated right into the loop body. We fixed
this by pointing the builder to the BB after the loop, as soon as code
generation of the loop body itself is finished.
llvm-svn: 150480
Before this change we built the CFG such that it was only valid after code was
fully generated. During code generation itself, it was often incomplete. After
this change always maintain a valid CFG. This will later allow us to use the
SCEVExpander during code generation. This is the first step to get rid of the
independent blocks pass.
llvm-svn: 150339
Such a dead code elimination can remove redundant stores to arrays. It can also
eliminate calculations where the results are stored to memory but where they are
overwritten before ever being read. It may also fix bugs like:
http://llvm.org/bugs/show_bug.cgi?id=5117
This commit just adds a sceleton without any functionality.
If anybody is interested to learn about polyhedral optimizations this would be
a good task. Well definined, self contained and pretty simple. Ping me if you
want to start and you need some pointers to get going.
llvm-svn: 149386
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
Tobias Grosser