the name of %fsr (as the comment in SparcV9RegClassInfo.h used to suggest)
you would walk off the end of the FloatCCRegName array.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13070 91177308-0d34-0410-b5e6-96231b3b80d8
wrapper idea uniformly: we can use Value::replaceAllUsesWith() instead of
special-casing by class of user.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13063 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove #include
* Add some methods to update loop/loopinfo
* Stop explicitly holding the loop depth in the Loop class. Instead, just
dynamically calculate it. This makes it easier to update LoopInfo as a
result of transformations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13059 91177308-0d34-0410-b5e6-96231b3b80d8
by creating an internal wrapper function with same signature as the external
function, and use it instead of the "real" function.
The wrapper then calls the external function using the same JIT function
resolution API that has been used before for rewriting instructions, since the
wrapper has an explicit call instruction which we can rewrite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13054 91177308-0d34-0410-b5e6-96231b3b80d8
structure to being dynamically computed on demand. This makes updating
loop information MUCH easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13045 91177308-0d34-0410-b5e6-96231b3b80d8
that the exit block of the loop becomes the new entry block of the function.
This was causing a verifier assertion on 252.eon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13039 91177308-0d34-0410-b5e6-96231b3b80d8
block. The primary motivation for doing this is that we can now unroll nested loops.
This makes a pretty big difference in some cases. For example, in 183.equake,
we are now beating the native compiler with the CBE, and we are a lot closer
with LLC.
I'm now going to play around a bit with the unroll factor and see what effect
it really has.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13034 91177308-0d34-0410-b5e6-96231b3b80d8
limited. Even in it's extremely simple state (it can only *fully* unroll single
basic block loops that execute a constant number of times), it already helps improve
performance a LOT on some benchmarks, particularly with the native code generators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13028 91177308-0d34-0410-b5e6-96231b3b80d8
operations. This allows us to compile this testcase:
int main() {
int h = 1;
do h = 3 * h + 1; while (h <= 256);
printf("%d\n", h);
return 0;
}
into this:
int %main() {
entry:
call void %__main( )
%tmp.6 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([4 x sbyte]* %.str_1, long 0, long 0), int 364 ) ; <int> [#uses=0]
ret int 0
}
This testcase was taken directly from 256.bzip2, believe it or not.
This code is not as general as I would like. Next up is to refactor it
a bit to handle more cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13019 91177308-0d34-0410-b5e6-96231b3b80d8
even if the loop is using expressions that we can't compute as a closed-form.
This allows us to calculate that this function always returns 55:
int test() {
double X;
int Count = 0;
for (X = 100; X > 1; X = sqrt(X), ++Count)
/*empty*/;
return Count;
}
And allows us to compute trip counts for loops like:
int h = 1;
do h = 3 * h + 1; while (h <= 256);
(which occurs in bzip2), and for this function, which occurs after inlining
and other optimizations:
int popcount()
{
int x = 666;
int result = 0;
while (x != 0) {
result = result + (x & 0x1);
x = x >> 1;
}
return result;
}
We still cannot compute the exit values of result or h in the two loops above,
which means we cannot delete the loop, but we are getting closer. Being able to
compute a constant trip count for these two loops will allow us to unroll them
completely though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13017 91177308-0d34-0410-b5e6-96231b3b80d8
