When doing SCEV based code generation, we ignore instructions calculating values
that are fully defined by a SCEV expression. The values that are calculated by
this instructions are recalculated on demand.
This commit improves the check to verify if certain instructions can be ignored
and recalculated on demand.
llvm-svn: 177313
In my previous commits I failed to realise that my new requires lines fully
disabled these tests. We now properly check if we are in an asserts build and
only disable the tests if assertions are not available.
Reported-by: Sean Silva <silvas@purdue.edu>
llvm-svn: 176900
This fixes issues caused by the following commit:
r176733 | jvoung | 2013-03-08 17:56:31 -0500
Disable statistics on Release builds and move tests that depend on -stats.
Reported by: Jack Howarth <howarth@bromo.med.uc.edu>
llvm-svn: 176856
We need to remove one dimension. Any is correct as long as it exists. We have
choosen for whatever reason the dimension #dims - 2. This is incorrect if
there is just one dimension. For CLooG this case did never happen. For isl
however, the case can happen and causes undefined behavior including crashes.
We choose now always the last dimension #dims - 1. We could have choosen
dimension '0' but the last dimension is what we remove conceptionally in the
algorithm, so it seems better to actually program it that way.
While at it remove another piece of undefined behavior.
llvm-svn: 174894
We now show the all members of the alias set that may couse possible aliasing.
In case a alias set member is not a named instruction (unnamed instructions or
constant expressions), we show the expression itself.
This improves our error message
from:
Possible aliasing for value: .reg2mem
to:
Possible aliasing: ".reg2mem",
"[0 x double]* inttoptr (i64 47255179264 to [0 x double]*)
llvm-svn: 174329
We fix the following formatting problems found by clang-format:
- 80 cols violations
- Obvious problems with missing or too many spaces
- multiple new lines in a row
clang-format suggests many more changes, most of them falling in the following
two categories:
1) clang-format does not at all format a piece of code nicely
2) The style that clang-format suggests does not match the style used in
Polly/LLVM
I consider differences caused by reason 1) bugs, which should be fixed by
improving clang-format. Differences due to 2) need to be investigated closer
to understand the cause of the difference and the solution that should be taken.
llvm-svn: 171241
Sebastian Pop