| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
loaded.
This fixes PR2599.
llvm-svn: 54133
|
| |
|
|
|
|
|
| |
command-line option, and disable it by default. It introduced performance
regressions because CodeGen is currently not able to remat such loads.
llvm-svn: 53997
|
| |
|
|
|
|
|
|
|
|
|
| |
case for this.
This allows instructions like loads from global variables declared to
be constant to be moved out of loops."
Patch by Stefanus Du Toit!
llvm-svn: 53945
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove the GetResultInst instruction. It is still accepted in LLVM assembly
and bitcode, where it is now auto-upgraded to ExtractValueInst. Also, remove
support for return instructions with multiple values. These are auto-upgraded
to use InsertValueInst instructions.
The IRBuilder still accepts multiple-value returns, and auto-upgrades them
to InsertValueInst instructions.
llvm-svn: 53941
|
| |
|
|
| |
llvm-svn: 53880
|
| |
|
|
|
|
|
|
|
| |
leads into a cycle involving a different PHI, LSR got stuck running
around that cycle looking for the original PHI. To avoid this, keep
track of visited PHIs and stop searching if we see one more than once.
This fixes PR2570.
llvm-svn: 53879
|
| |
|
|
| |
llvm-svn: 53716
|
| |
|
|
| |
llvm-svn: 53715
|
| |
|
|
| |
llvm-svn: 53675
|
| |
|
|
|
|
| |
deadargelim leaves behind :-)
llvm-svn: 53674
|
| |
|
|
| |
llvm-svn: 53666
|
| |
|
|
|
|
| |
it work again tomorrow.
llvm-svn: 53614
|
| |
|
|
|
|
|
|
| |
allowed to canonicalize return values).
Add a test that checks if return value and function attributes are not removed.
llvm-svn: 53612
|
| |
|
|
| |
llvm-svn: 53611
|
| |
|
|
|
|
|
|
|
|
|
|
| |
return values that are still (partially) live. Instead of updating all uses of
a call instruction after removing some elements, it now just rebuilds the
original struct (With undef gaps where the unused values were) and leaves it to
instcombine to clean this up.
The added testcase still fails currently, but this is due to instcombine which
isn't good enough yet. I will fix that part next.
llvm-svn: 53608
|
| |
|
|
| |
llvm-svn: 53605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
disproving a condition. This actually compiles the existing testcase
(udiv_select_to_select_shift) to:
define i64 @test(i64 %X, i1 %Cond) {
entry:
%divisor1.t = lshr i64 %X, 3 ; <i64> [#uses=1]
%quotient2 = lshr i64 %X, 3 ; <i64> [#uses=1]
%sum = add i64 %divisor1.t, %quotient2 ; <i64> [#uses=1]
ret i64 %sum
}
instead of:
define i64 @test(i64 %X, i1 %Cond) {
entry:
%quotient1.v = select i1 %Cond, i64 3, i64 4 ; <i64> [#uses=1]
%quotient1 = lshr i64 %X, %quotient1.v ; <i64> [#uses=1]
%quotient2 = lshr i64 %X, 3 ; <i64> [#uses=1]
%sum = add i64 %quotient1, %quotient2 ; <i64> [#uses=1]
ret i64 %sum
}
llvm-svn: 53534
|
| |
|
|
|
|
| |
fixes PR2540.
llvm-svn: 53533
|
| |
|
|
|
|
|
| |
Remove dead code analyzing urem. 'urem' of power-of-2 is canonicalized to an
'and' instruction.
llvm-svn: 53506
|
| |
|
|
|
|
| |
similar.
llvm-svn: 53451
|
| |
|
|
|
|
|
| |
was using the algorithm for folding unsigned comparisons which is
completely wrong. This has been broken since the signless types change.
llvm-svn: 53444
|
| |
|
|
|
|
|
|
|
|
|
| |
true)
This cause a regression in InstCombine/JavaCompare, which was doing the right
thing on accident. To handle the missed case, generalize the comparisons based
on masked bits a little bit to handle comparisons against the max value. For
example, we can now xform (slt i32 (and X, 4), 4) -> (setne i32 (and X, 4), 4)
llvm-svn: 53443
|
| |
|
|
| |
llvm-svn: 53442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the DeadArgumentElimination pass, to use a more explicit tracking of
dependencies between return values and/or arguments. Also make the handling of
arguments and return values the same.
The pass now looks properly inside returned structs, but only at the first
level (ie, not inside nested structs).
This version fixed a few more bugs and was cleaned up a bit. It now passes all
of LLVM's testing, and should still pass SPEC2006. There is still a minor bug
with regard to returning nested structs. Since there is currently nothing that
emits such IR, I will fix that in a seperate commit (partly because it requires
a non-trivial fix).
llvm-svn: 53400
|
| |
|
|
| |
llvm-svn: 53393
|
| |
|
|
|
|
| |
infinite recursion. part of PR2529
llvm-svn: 53383
|
| |
|
|
|
|
| |
it for PR2529
llvm-svn: 53380
|
| |
|
|
| |
llvm-svn: 53282
|
| |
|
|
| |
llvm-svn: 53276
|
| |
|
|
| |
llvm-svn: 53273
|
| |
|
|
| |
llvm-svn: 53271
|
| |
|
|
|
|
| |
not split the loop.
llvm-svn: 53265
|
| |
|
|
| |
llvm-svn: 53242
|
| |
|
|
| |
llvm-svn: 53239
|
| |
|
|
|
|
|
|
|
|
|
| |
1) evaluate [v]fcmp true/false with undefs to true or false instead
of undef.
2) fix vector comparisons with undef to return a vector result instead
of i1
3) fix vector comparisons with evaluatable results to return vector
true/false instead of i1 true/false (PR2529)
llvm-svn: 53220
|
| |
|
|
| |
llvm-svn: 53151
|
| |
|
|
|
|
| |
because, as Eli pointed out, SimplifyCFG already does this.
llvm-svn: 53104
|
| |
|
|
|
|
| |
part of PR2509.
llvm-svn: 53038
|
| |
|
|
|
|
| |
unreachable blocks.
llvm-svn: 53032
|
| |
|
|
| |
llvm-svn: 52795
|
| |
|
|
| |
llvm-svn: 52784
|
| |
|
|
| |
llvm-svn: 52702
|
| |
|
|
| |
llvm-svn: 52688
|
| |
|
|
|
|
|
|
| |
failures fixed.
Also add a testcase to reproduce the gcc bootstrap failure in very much reduced form.
llvm-svn: 52677
|
| |
|
|
|
|
|
|
| |
in the presence of out-of-loop users of in-loop values and the trip
count is not a known multiple of the unroll count, and to be a bit
simpler overall. This fixes PR2253.
llvm-svn: 52645
|
| |
|
|
|
|
| |
with more than two nodes.
llvm-svn: 52617
|
| |
|
|
|
|
|
|
|
| |
structures. Its default threshold is to promote things that are
smaller than 128 bytes, which is sane. However, it is not sane
to do this for things that turn into 128 *registers*. Add a cap
on the number of registers introduced, defaulting to 128/4=32.
llvm-svn: 52611
|
| |
|
|
|
|
|
|
| |
15).
See also PR1800, which is about the signed case.
llvm-svn: 52608
|
| |
|
|
| |
llvm-svn: 52596
|
| |
|
|
| |
llvm-svn: 52570
|