| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 327857
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the time of code generation, an instruction with an llvm intrinsic is ignored
in copyBB. However, if the value of the instruction is used later in the
program, the value needs to be synthesized. However, this is causing some issues
with the instructions being generated in a hoisted basic block.
Removing llvm.expect from the list of ignored intrinsics fixes this bug.
This resolves http://llvm.org/PR32324.
Contributed-by: Annanay Agarwal <cs14btech11001@iith.ac.in>
Tags: #polly
Differential Revision: https://reviews.llvm.org/D32992
llvm-svn: 303006
|
|
|
|
|
|
|
|
|
|
|
|
| |
This release includes sevaral improvments compared to the previous
version isl-0.16.1-145-g243bf7c (from the ISL 0.17 announcement):
- optionally combine SCCs incrementally in scheduler
- optionally maximize coincidence in scheduler
- optionally avoid loop coalescing in scheduler
- minor AST generator improvements
- improve support for expansions in schedule trees
llvm-svn: 268500
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 2879c53e80e05497f408f21ce470d122e9f90f94.
Additionally, it adds SDiv and SRem instructions to the set of values
discovered by the findValues function even if we add the operands to
be able to recompute the SCEVs. In subfunctions we do not want to
recompute SDiv and SRem instructions but pass them instead as they
might have been created through the IslExprBuilder and are more
complicated than simple SDiv/SRem instructions in the code.
llvm-svn: 265873
|
|
|
|
| |
llvm-svn: 169159
|
|
|
|
|
|
| |
Buildbot failure at r168785.
llvm-svn: 168791
|
|
|
|
| |
llvm-svn: 168724
|
|
|
|
|
|
| |
This allows Polly to vectorize more code. Fix the relevant test cases.
llvm-svn: 167923
|
|
|
|
|
|
|
| |
Use 'opt < %s' instead of just 'opt %s' to ensure that no temporary files are
created.
llvm-svn: 167372
|
|
|
|
| |
llvm-svn: 167284
|
|
|
|
| |
llvm-svn: 167283
|
|
|
|
|
|
|
|
| |
Similar to LLVM we now follow the policy of only having LLVM-IR level tests in
the Polly test suite. Testing for miscompilation of larger programs should be
done with the llvm test suite.
llvm-svn: 167255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The detection of values that need to be copied in to the generated OpenMP
subfunction also detects the array base addresses needed in the SCoP. Hence, it
is not necessary to unconditionally copy all the base addresses to the generated
function.
Test cases are modified to reflect this change. Arrays which are global
variables do not occur in the struct passed to the subfunction anymore. A test
case for base address copy-in is added in copy_in_array.{c,ll}.
Committed with slight modifications
Contributed by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
llvm-svn: 167215
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to the arrays and clast variables a SCoP statement may also refer to
values defined before the SCoP or to function arguments. Detect these values and
add them to the set of values passed to the function generated for OpenMP
parallel execution of a clast.
Committed with additional test cases and some refactoring.
Contributed by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
llvm-svn: 167214
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating OpenMP or GPGPU code the original ValueMap and ClastVars must be
kept. We already recovered the original ClastVars by reverting the changes, but
we did not keep the content of the ValueMap. This patch keeps now an explicit
copy of both maps and restores them after generating OpenMP or GPGPU code.
This is an adapted version of a patch contributed by:
Armin Groesslinger <armin.groesslinger@uni-passau.de>
llvm-svn: 167213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 156255
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 155438
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 153645
|
|
|
|
| |
llvm-svn: 153440
|
|
|
|
|
|
| |
The prefix is not needed, as all test cases are already in a separate folder.
llvm-svn: 153320
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 151916
|
|
|
|
| |
llvm-svn: 151912
|
|
|
|
| |
llvm-svn: 150575
|
|
|
|
| |
llvm-svn: 150377
|
|
|
|
| |
llvm-svn: 150337
|
|
|
|
| |
llvm-svn: 150335
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This fixes the test with recent versions of LLVM that do not support
the old atomic instructions any more.
llvm-svn: 145402
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 139097
|
|
|
|
| |
llvm-svn: 139095
|
|
|
|
|
|
|
|
|
| |
It may happen that we generate the code of a basic block from the original
scop is code generated several times. The new naming scheme reduces confusing
that earlier appeared as the version numbers of the new basic blocks could
have been interpreted as part of the name of the original basic block.
llvm-svn: 139092
|
|
|
|
|
|
|
| |
Support for generating code for an access function change which is
a constant is added.
llvm-svn: 137603
|
|
|
|
|
|
|
|
| |
Code is generated for a simple access function change imported
from JSCOP file. An access of A[i] is changed to A[0]. The code
for A[0] is generated directly without refering to isl function calls.
llvm-svn: 136789
|
|
|
|
|
|
|
| |
The changed access relations imported from JSCOP file is shown
as output of -analyze pass.
llvm-svn: 136774
|
|
|
|
|
|
|
| |
This patch reads the change in access functions from
imported JSCOP file. A test case is also added.
llvm-svn: 134991
|
|
|
|
|
|
|
| |
Remove constness of Types and do not name the structures generated in the OpenMP
code.
llvm-svn: 134980
|
|
|
|
|
|
|
| |
The construct '< %s' complicates debugging with gdb --args as the content of
%s is interpreted as gdb input.
llvm-svn: 134432
|
|
|
|
|
|
|
| |
The latest version of LLVM fails, if a function is defined twice in an LLVM
bitcode file.
llvm-svn: 134400
|
|
|
|
|
|
|
| |
Instead of deleting the old code, keep it on the side in an if-branch. It will
either be deleted by the dead code elimination or we can use it as fallback.
llvm-svn: 131352
|