Orignally, we first test if a ValueMap contains a Value, and than use the
index operator to get the corresponding new value. This requires the ValueMap
to lookup the key (i.e. the old value) twice.
Now, we directly use the "lookup" function provided by DenseMap to implement
the same functionality.
llvm-svn: 185260
1. Do not allow creating new memory access record in the InstructionToAccess map
on the fly in function getAccessFor.
2. Do not allow user to modify the memory accesses returned by getAccessFor
during the code generation process.
llvm-svn: 185253
isl recently introduced isl_val as an abstract interface to represent arbitrary
precision numbers. This interface superseeds the old isl_int interface. In
contrast to the old interface which implemented arbitrary precision arithmetic
using macros that forward to the gmp library, the new library hides the math
library implementation in isl. This allows us to switch the math library used by
isl without affecting users such as Polly.
llvm-svn: 184529
Previously this happend to work for integers up to i64, but we got it wrong
for larger numbers. Fix this and add test cases to verify this keeps working.
Reported by: Sven Verdoolaege <skimo at kotnet dot org>
llvm-svn: 183986
When a region header is part of a loop, then all entering edges of this region
should not come from the loop but outside the region. Otherwise, the loop may be
only partially part of the region, which would cause troubles in handling
induction variables.
Currently, we can only model induction variables that are either fully part of
the scop (loop induction variable) or induction variables that are scop-
invariant (parameter). A loop that is only partially part of the
scop causes troubles, as there is no good way to handle the induction
variable in the independent blocks pass.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 183800
The latest version of isl includes a new data type isl_val, which properly hides
the multi precision math library used by isl. In Polly we would like to replace
all uses of isl_int with the corresponding isl_val interfaces. This will allow
us to switch the multi precision math library in isl. This is especially
interesting for people who would like to replace libgmp with a non-gpl licensed
library (e.g. imath).
llvm-svn: 183026
The original test case showed a problem with the independet blocks pass and
we decided to XFAIL it for now. Unfortunately the failure is not detected if
we build without asserts and the verification of the independent block pass
is not run. This change tests now for the actual reason of the failure and
should trigger even in a non asserts build. We did not yet solve the underlying
bug, but this should at least make the test suite behavior consistent.
llvm-svn: 183025
In GDB when "step" through generateScalarLoad and "finish" the call, the
returned value is non NULL, however when printing the value contained in
BBMap[Load] after this stmt:
BBMap[Load] = generateScalarLoad(...);
the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1.
The only intuitive idea that I have to explain this behavior is that we are
playing with the undefined behavior of eval order of the params for the function
standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be
executed before generateScalarLoad is called.
Here are some other possible explanations from Will Dietz <w@wdtz.org>:
The error is likely due to BBMap[Load] being evaluated first (creating
a {Load -> uninitialized } entry in the DenseMap), then
generateScalarLoad eventually accesses the same element and finds it
to be NULL (DenseMap[Old]).. Offhand I'm not sure if this is
guaranteed to be NULL or if it's uninitialized and happens to be NULL.
The same issue can also go wrong in an even worse way: the second
DenseMap access can trigger a rehash and *invalidate* the an earlier
evaluated expression (for example LHS of the assignment), leading to a
crash when performing the assignment store.
llvm-svn: 182655
It was initially committed to allow people to get a list of the files used
or generated in the matmul tutorial. Since the documentation does now
point people to the directory in their git checkout, it is not necessary anymore
to make a directory listing available. Especially, as this never worked and
recently the LLVM web server does not deliver files in this directory at all
due to the unsupported .htaccess file.
llvm-svn: 182370
As the namings of the scops have changed, polly was not able to read in the user
given .jscop files. By renaming the provided files, polly now finds them again
and can use them to optimize the matmul function. We also update the generated
files to reflect the very latest version of Polly.
llvm-svn: 182265
When the Polly code generation was written we did not correctly update the
LoopInfo data, but still claimed that the loop information is correct. This
does not only lead to missed optimizations, but it can also cause
miscompilations in case passes such as LoopSimplify are run after Polly.
Reported-by: Sergei Larin <slarin@codeaurora.org>
llvm-svn: 181987
BeforeBB
|
v
GuardBB
/ \
__ PreHeaderBB \
/ \ / |
latch HeaderBB |
\ / \ /
< \ /
\ /
ExitBB
This does not only remove the need for an explicit loop rotate pass, but it also
gives us the possibility to skip the construction of the guard condition in case
the loop is known to be executed at least once. We do not yet exploit this, but
by implementing this analysis in the isl code generator we should be able to
remove more guards than the generic loop rotate pass can. Another point is that
loop rotation can introduce additional PHI nodes, which may hide that a loop can
be executed in parallel. This change avoids this complication and will make it
easier to move the openmp code generation into a separate pass.
llvm-svn: 181986
Tobias Grosser