| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
all but main. If it's not set, we can still internalize, but only if an
explicit symbol list is provided.
llvm-svn: 23783
|
| |
|
|
| |
llvm-svn: 23773
|
| |
|
|
| |
llvm-svn: 23772
|
| |
|
|
| |
llvm-svn: 23771
|
| |
|
|
|
|
|
| |
out CSE's of base expressions it could build a result whose order was
nondet.
llvm-svn: 23698
|
| |
|
|
|
|
| |
from the end of a vector instead of the beginning
llvm-svn: 23697
|
| |
|
|
| |
llvm-svn: 23695
|
| |
|
|
| |
llvm-svn: 23677
|
| |
|
|
| |
llvm-svn: 23674
|
| |
|
|
| |
llvm-svn: 23673
|
| |
|
|
|
|
|
| |
IV strides dependend on the pointer order of the strides in memory.
Non-determinism is bad.
llvm-svn: 23672
|
| |
|
|
| |
llvm-svn: 23656
|
| |
|
|
| |
llvm-svn: 23618
|
| |
|
|
|
|
|
| |
and more correct than use_empty(). This fixes PR635 and
SimplifyCFG/2005-10-02-InvokeSimplify.ll
llvm-svn: 23616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
particular, it should realize that phi's use their values in the pred block
not the phi block itself. This change turns our em3d loop from this:
_test:
cmpwi cr0, r4, 0
bgt cr0, LBB_test_2 ; entry.no_exit_crit_edge
LBB_test_1: ; entry.loopexit_crit_edge
li r2, 0
b LBB_test_6 ; loopexit
LBB_test_2: ; entry.no_exit_crit_edge
li r6, 0
LBB_test_3: ; no_exit
or r2, r6, r6
lwz r6, 0(r3)
cmpw cr0, r6, r5
beq cr0, LBB_test_6 ; loopexit
LBB_test_4: ; endif
addi r3, r3, 4
addi r6, r2, 1
cmpw cr0, r6, r4
blt cr0, LBB_test_3 ; no_exit
LBB_test_5: ; endif.loopexit.loopexit_crit_edge
addi r3, r2, 1
blr
LBB_test_6: ; loopexit
or r3, r2, r2
blr
into:
_test:
cmpwi cr0, r4, 0
bgt cr0, LBB_test_2 ; entry.no_exit_crit_edge
LBB_test_1: ; entry.loopexit_crit_edge
li r2, 0
b LBB_test_5 ; loopexit
LBB_test_2: ; entry.no_exit_crit_edge
li r6, 0
LBB_test_3: ; no_exit
lwz r2, 0(r3)
cmpw cr0, r2, r5
or r2, r6, r6
beq cr0, LBB_test_5 ; loopexit
LBB_test_4: ; endif
addi r3, r3, 4
addi r6, r6, 1
cmpw cr0, r6, r4
or r2, r6, r6
blt cr0, LBB_test_3 ; no_exit
LBB_test_5: ; loopexit
or r3, r2, r2
blr
Unfortunately, this is actually worse code, because the register coallescer
is getting confused somehow. If it were doing its job right, it could turn the
code into this:
_test:
cmpwi cr0, r4, 0
bgt cr0, LBB_test_2 ; entry.no_exit_crit_edge
LBB_test_1: ; entry.loopexit_crit_edge
li r6, 0
b LBB_test_5 ; loopexit
LBB_test_2: ; entry.no_exit_crit_edge
li r6, 0
LBB_test_3: ; no_exit
lwz r2, 0(r3)
cmpw cr0, r2, r5
beq cr0, LBB_test_5 ; loopexit
LBB_test_4: ; endif
addi r3, r3, 4
addi r6, r6, 1
cmpw cr0, r6, r4
blt cr0, LBB_test_3 ; no_exit
LBB_test_5: ; loopexit
or r3, r6, r6
blr
... which I'll work on next. :)
llvm-svn: 23604
|
| |
|
|
| |
llvm-svn: 23603
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memoizing code when IV's are used by phinodes outside of loops. In a simple
example, we were getting this code before (note that r6 and r7 are isomorphic
IV's):
li r6, 0
or r7, r6, r6
LBB_test_3: ; no_exit
lwz r2, 0(r3)
cmpw cr0, r2, r5
or r2, r7, r7
beq cr0, LBB_test_5 ; loopexit
LBB_test_4: ; endif
addi r2, r7, 1
addi r7, r7, 1
addi r3, r3, 4
addi r6, r6, 1
cmpw cr0, r6, r4
blt cr0, LBB_test_3 ; no_exit
Now we get:
li r6, 0
LBB_test_3: ; no_exit
or r2, r6, r6
lwz r6, 0(r3)
cmpw cr0, r6, r5
beq cr0, LBB_test_6 ; loopexit
LBB_test_4: ; endif
addi r3, r3, 4
addi r6, r2, 1
cmpw cr0, r6, r4
blt cr0, LBB_test_3 ; no_exit
this was noticed in em3d.
llvm-svn: 23602
|
| |
|
|
|
|
|
|
| |
check the presplit pred, not the post-split pred. This was causing us
to make the wrong decision in some cases, leaving the critical edge block
in the loop.
llvm-svn: 23601
|
| |
|
|
| |
llvm-svn: 23579
|
| |
|
|
|
|
| |
LowerInvoke/2005-08-03-InvokeWithPHI.ll
llvm-svn: 23525
|
| |
|
|
|
|
| |
bringing the LLC time down to the CBE time.
llvm-svn: 23521
|
| |
|
|
| |
llvm-svn: 23519
|
| |
|
|
| |
llvm-svn: 23517
|
| |
|
|
| |
llvm-svn: 23487
|
| |
|
|
|
|
| |
to right now.
llvm-svn: 23485
|
| |
|
|
|
|
| |
and PR632.
llvm-svn: 23484
|
| |
|
|
| |
llvm-svn: 23478
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is performed so it is only at most once per function that contains an invoke
instead of once per invoke in the function. This patch has the following perks:
1. It fixes PR631, which complains about slowness.
2. If fixes PR240, which complains about non-volatile vars being live across
setjmp/longjmps.
3. It improves (but does not fix) the jmpbuf alignment issue on itanium by not
forcing the jmpbufs to always be 8-bytes off the alignment of the structure.
4. It speeds up 253.perlbmk from 338s to 13.70s (a 25x improvement!), making us
now about 4% faster than GCC.
Further improvements are also possible.
llvm-svn: 23477
|
| |
|
|
| |
llvm-svn: 23476
|
| |
|
|
| |
llvm-svn: 23473
|
| |
|
|
|
|
|
|
| |
implements
ctor-list-opt.ll:CTOR8
llvm-svn: 23465
|
| |
|
|
|
|
| |
potentially replaced at link-time.
llvm-svn: 23463
|
| |
|
|
|
|
|
|
| |
because gccas runs globalopt before inlining.
This implements ctor-list-opt.ll:CTOR7
llvm-svn: 23462
|
| |
|
|
| |
llvm-svn: 23460
|
| |
|
|
| |
llvm-svn: 23453
|
| |
|
|
| |
llvm-svn: 23452
|
| |
|
|
| |
llvm-svn: 23450
|
| |
|
|
|
|
| |
ctor-list-opt.ll:CTOR5.
llvm-svn: 23449
|
| |
|
|
| |
llvm-svn: 23447
|
| |
|
|
|
|
| |
ConstantFoldLoadThroughGEPConstantExpr function in the utils lib.
llvm-svn: 23446
|
| |
|
|
|
|
| |
as ConstantFoldLoadThroughGEPConstantExpr.
llvm-svn: 23445
|
| |
|
|
|
|
| |
pass.
llvm-svn: 23444
|
| |
|
|
| |
llvm-svn: 23442
|
| |
|
|
| |
llvm-svn: 23441
|
| |
|
|
| |
llvm-svn: 23439
|
| |
|
|
|
|
| |
global ctors that are simple enough. This implements ctor-list-opt.ll:CTOR2.
llvm-svn: 23437
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 23435
|
| |
|
|
|
|
| |
accepting the null even with a non-65535 init prio
llvm-svn: 23434
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the start of global ctor optimization. It is currently smart
enough to remove the global ctor for cases like this:
struct foo {
foo() {}
} x;
... saving a bit of startup time for the program.
llvm-svn: 23433
|
| |
|
|
|
|
| |
SimplifyLibCalls/2005-05-20-sprintf-crash.ll
llvm-svn: 23430
|