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
Before we defined GPGPU_CODEGEN to '0', which does not disable the relevant code
as we just check if that value is defined at all. We now follow the cmake
approach and only define GPGPU_CODEGEN, if the feature should be enabled.
Reported by: Sebastian Pop <spop@codeaurora.org>
llvm-svn: 162275
Added a file that explains how to load Polly in dragonegg.
Also fixed a typo in the document for clang.
Committed with a typo fix and a change to make this website available from
the documentation section.
Contributed by: Sameer Sahasrabuddhe <Sameer.Sahasrabuddhe@amd.com>
llvm-svn: 161928
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
This fixes a conflict between polly::createIndVarSimplifyPass() and
llvm::createIndVarSimplifyPass(), which causes problems on windows.
Reported by: Michael Kruse <MichaelKruse@meinersbur.de
llvm-svn: 161235
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
Otherwise the script spams the home directory and, in case there are folders
of previous attempts lying around, it may fail in some unexpected way.
llvm-svn: 160677
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
The "llvm.codegen" intrinsic patch is a patch to LLVM, which is used
to generate code for embedded LLVM-IR strings. In Polly, we use it
to generate ptx assembly text for GPGPU code generation.
llvm-svn: 157689
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
dependent list for target polly-test, hence making "all" from the top
of llvm build directory will cause the target "polly-test" being built
before its dependencing target built.
Patched by Sebastian Pop<spop@codeaurora.org>
llvm-svn: 154162
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
Tobias Grosser