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
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
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
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
Instead of using TempScop to find parameters, we detect them directly
on the SCEV. This allows us to remove the TempScop parameter detection
in a subsequent commit.
This fixes a bug reported by Marcello Maggioni <hayarms@gmail.com>
llvm-svn: 144087
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
Due to the recent introduction of isl_id, parameters need now always to be
aligned. This was not yet taken care of in the code path of vectorization and
dependence analysis.
llvm-svn: 138555
I am planning to eliminate the TempScopInfo pass. To simplify this I remove
some features that may later be added to the ScopInfo pass.
The interchange pass is currently strongly tested and furthermore ment to be
replaced by the general scheduling optimizer. Reductions itself can later
be added easily.
llvm-svn: 138219
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
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
Tobias Grosser