| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
br (and X, phi(Y, Z, false)), label L1, label L2
This triggers once on 252.eon and 6 times on 176.gcc. Blocks
in question often look like this:
bb262: ; preds = %bb261, %bb248
%iftmp.251.0 = phi i1 [ true, %bb261 ], [ false, %bb248 ] ; <i1> [#uses=4]
%tmp270 = icmp eq %struct.rtx_def* %tmp.0.i, null ; <i1> [#uses=1]
%bothcond = or i1 %iftmp.251.0, %tmp270 ; <i1> [#uses=1]
br i1 %bothcond, label %bb288, label %bb273
In this case, it is clear that it doesn't matter if tmp.0.i is null when coming from bb261. When coming from bb248, it is all that matters.
Another random example:
check_asm_operands.exit: ; preds = %check_asm_operands.exit.thr_comm, %bb30.i, %bb12.i, %bb6.i413
%tmp.0.i420 = phi i1 [ true, %bb6.i413 ], [ true, %bb12.i ], [ true, %bb30.i ], [ false, %check_asm_operands.exit.thr_comm ; <i1> [#uses=1]
call void @llvm.stackrestore( i8* %savedstack ) nounwind
%tmp4389 = icmp eq i32 %added_sets_1.0, 0 ; <i1> [#uses=1]
%tmp4394 = icmp eq i32 %added_sets_2.0, 0 ; <i1> [#uses=1]
%bothcond80 = and i1 %tmp4389, %tmp4394 ; <i1> [#uses=1]
%bothcond81 = and i1 %bothcond80, %tmp.0.i420 ; <i1> [#uses=1]
br i1 %bothcond81, label %bb4398, label %bb4397
Here is the case from 252.eon:
bb290.i.i: ; preds = %bb23.i57.i.i, %bb8.i39.i.i, %bb100.i.i, %bb100.i.i, %bb85.i.i110
%myEOF.1.i.i = phi i1 [ true, %bb100.i.i ], [ true, %bb100.i.i ], [ true, %bb85.i.i110 ], [ true, %bb8.i39.i.i ], [ false, %bb23.i57.i.i ] ; <i1> [#uses=2]
%i.4.i.i = phi i32 [ %i.1.i.i, %bb85.i.i110 ], [ %i.0.i.i, %bb100.i.i ], [ %i.0.i.i, %bb100.i.i ], [ %i.3.i.i, %bb8.i39.i.i ], [ %i.3.i.i, %bb23.i57.i.i ] ; <i32> [#uses=3]
%tmp292.i.i = load i8* %tmp16.i.i100, align 1 ; <i8> [#uses=1]
%tmp293.not.i.i = icmp ne i8 %tmp292.i.i, 0 ; <i1> [#uses=1]
%bothcond.i.i = and i1 %tmp293.not.i.i, %myEOF.1.i.i ; <i1> [#uses=1]
br i1 %bothcond.i.i, label %bb202.i.i, label %bb301.i.i
Factoring out 3 common predecessors.
On the path from any blocks other than bb23.i57.i.i, the load and compare
are dead.
llvm-svn: 50096
|
|
|
|
| |
llvm-svn: 50093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getelementptr-seteq.ll into:
define i1 @test(i64 %X, %S* %P) {
%C = icmp eq i64 %X, -1 ; <i1> [#uses=1]
ret i1 %C
}
instead of:
define i1 @test(i64 %X, %S* %P) {
%A.idx.mask = and i64 %X, 4611686018427387903 ; <i64> [#uses=1]
%C = icmp eq i64 %A.idx.mask, 4611686018427387903 ; <i1> [#uses=1]
ret i1 %C
}
And fixes the second half of PR2235. This speeds up the insertion sort
case by 45%, from 1.12s to 0.77s. In practice, this will significantly
speed up for loops structured like:
for (double *P = Base + N; P != Base; --P)
...
Which happens frequently for C++ iterators.
llvm-svn: 50079
|
|
|
|
|
|
| |
and simplify code that was fallout from the separation of memcpyopt and gvn.
llvm-svn: 50034
|
|
|
|
| |
llvm-svn: 49971
|
|
|
|
|
|
|
| |
from transforming loops and adding a separate loop pass for removing
loops with know trip counts. Until that happens, ADCE is miscompiling this code.
llvm-svn: 49769
|
|
|
|
| |
llvm-svn: 49517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in addition to integer expressions. Rewrite GetOrEnforceKnownAlignment
as a ComputeMaskedBits problem, moving all of its special alignment
knowledge to ComputeMaskedBits as low-zero-bits knowledge.
Also, teach ComputeMaskedBits a few basic things about Mul and PHI
instructions.
This improves ComputeMaskedBits-based simplifications in a few cases,
but more noticeably it significantly improves instcombine's alignment
detection for loads, stores, and memory intrinsics.
llvm-svn: 49492
|
|
|
|
|
|
| |
figuring out the suffix to use. implement pow(2,x) -> exp2(x).
llvm-svn: 49437
|
|
|
|
| |
llvm-svn: 49436
|
|
|
|
|
|
| |
GVN and into its own pass.
llvm-svn: 49419
|
|
|
|
|
|
| |
add support for pow(x, 2.0) -> x*x.
llvm-svn: 49411
|
|
|
|
| |
llvm-svn: 49382
|
|
|
|
| |
llvm-svn: 48938
|
|
|
|
|
|
| |
transformed to undef. But this is such a common idiom (misuse) we are going to handle it.
llvm-svn: 48791
|
|
|
|
| |
llvm-svn: 48762
|
|
|
|
| |
llvm-svn: 48738
|
|
|
|
| |
llvm-svn: 48732
|
|
|
|
| |
llvm-svn: 48731
|
|
|
|
|
|
| |
at least one of the (zext icmp) can be transformed to eliminate an icmp.
llvm-svn: 48715
|
|
|
|
| |
llvm-svn: 48693
|
|
|
|
|
|
|
|
| |
This fires dozens of times across spec and multisource, but I don't know
if it actually speeds stuff up. Hopefully the testers will show something
nice :)
llvm-svn: 48680
|
|
|
|
|
|
|
|
| |
simplify things like (X & 4) >> 1 == 2 --> (X & 4) == 4.
since it is obvious that the shift doesn't remove any bits.
llvm-svn: 48631
|
|
|
|
| |
llvm-svn: 48538
|
|
|
|
| |
llvm-svn: 48536
|
|
|
|
| |
llvm-svn: 48530
|
|
|
|
| |
llvm-svn: 48529
|
|
|
|
| |
llvm-svn: 48527
|
|
|
|
| |
llvm-svn: 48484
|
|
|
|
| |
llvm-svn: 48483
|
|
|
|
|
|
|
|
| |
the type instead of the byte size. This was causing troublesome mis-compilations.
True to form, this took 2 days to find and is a one-line fix. :-P
llvm-svn: 48354
|
|
|
|
|
|
| |
pointer bitcast when performing return slot optimization.
llvm-svn: 48343
|
|
|
|
|
|
|
|
|
| |
to sret parameters), and
safer (when the passed pointer might be invalid). Thanks to Duncan and Chris for the idea behind this,
and extra thanks to Duncan for helping me work out the trap-safety.
llvm-svn: 48280
|
|
|
|
| |
llvm-svn: 48262
|
|
|
|
| |
llvm-svn: 48254
|
|
|
|
|
|
|
|
| |
before trying to merge the block into its predecessors.
This allows two-entry-phi-return.ll to be simplified
into a single basic block.
llvm-svn: 48252
|
|
|
|
|
|
| |
optimized away before it tests what it is intended to test.
llvm-svn: 48251
|
|
|
|
| |
llvm-svn: 48210
|
|
|
|
| |
llvm-svn: 48207
|
|
|
|
| |
llvm-svn: 48163
|
|
|
|
| |
llvm-svn: 48137
|
|
|
|
| |
llvm-svn: 48123
|
|
|
|
| |
llvm-svn: 48103
|
|
|
|
|
|
|
| |
Secondly, we have to check whether the branch is actually pointing to the block
with the unwind in it. We could have gotten here because of the unwind_to alone.
llvm-svn: 48099
|
|
|
|
|
|
| |
at all.
llvm-svn: 48096
|
|
|
|
| |
llvm-svn: 48086
|
|
|
|
|
|
| |
removal of invoke, PR1269.
llvm-svn: 48084
|
|
|
|
| |
llvm-svn: 48020
|
|
|
|
| |
llvm-svn: 48016
|
|
|
|
| |
llvm-svn: 47988
|