| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 132071
|
| |
|
|
|
|
| |
cleanup and overdue test cases.
llvm-svn: 132038
|
| |
|
|
| |
llvm-svn: 132025
|
| |
|
|
|
|
|
|
|
|
|
| |
case of a switch instruction. Back off this optimization when this would
eliminate all of the predecessors to the latch.
Sorry, I am unable to reduce a reasonably sized test case.
rdar://9486843
llvm-svn: 132022
|
| |
|
|
|
|
|
|
| |
constant is used many times.
Part of rdar://9471075.
llvm-svn: 131979
|
| |
|
|
| |
llvm-svn: 131956
|
| |
|
|
|
|
| |
promoting allocas to SSA variables. Fixes <rdar://problem/9479036>.
llvm-svn: 131953
|
| |
|
|
|
|
| |
This fixes PR9845.
llvm-svn: 131919
|
| |
|
|
|
|
|
|
| |
shift-exactness
xform recurse.
llvm-svn: 131888
|
| |
|
|
|
|
| |
in a known-non-zero context.
llvm-svn: 131887
|
| |
|
|
|
|
|
|
| |
checking
for a constant directly. Thanks to Duncan for pointing this out.
llvm-svn: 131885
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aligned.
Teach memcpyopt to not give up all hope when confonted with an underaligned
memcpy feeding an overaligned byval. If the *source* of the memcpy can be
determined to be adequeately aligned, or if it can be forced to be, we can
eliminate the memcpy.
This addresses PR9794. We now compile the example into:
define i32 @f(%struct.p* nocapture byval align 8 %q) nounwind ssp {
entry:
%call = call i32 @g(%struct.p* byval align 8 %q) nounwind
ret i32 %call
}
in both x86-64 and x86-32 mode. We still don't get a tailcall though,
because tailcalls apparently can't handle byval.
llvm-svn: 131884
|
| |
|
|
| |
llvm-svn: 131862
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that their
result is non-zero. Implement an example optimization (PR9814), which allows us to
transform:
A / ((1 << B) >>u 2)
into:
A >>u (B-2)
which we compile into:
_divu3: ## @divu3
leal -2(%rsi), %ecx
shrl %cl, %edi
movl %edi, %eax
ret
instead of:
_divu3: ## @divu3
movb %sil, %cl
movl $1, %esi
shll %cl, %esi
shrl $2, %esi
movl %edi, %eax
xorl %edx, %edx
divl %esi, %eax
ret
llvm-svn: 131860
|
| |
|
|
|
|
|
|
| |
failing to form a memset, then having to delete it" but my approximation
isn't safe for self recurrent loops. Instead of doign a hack, just
do it the right way.
llvm-svn: 131858
|
| |
|
|
|
|
|
|
| |
to also clean up the condition of any conditional terminator it folds to be unconditional, if that turns the condition into dead code. This just means it calls RecursivelyDeleteTriviallyDeadInstructions() in strategic spots. It defaults to the old behavior.
I also changed -simplifycfg, -jump-threading and -codegenprepare to use this to produce slightly better code without any extra cleanup passes (AFAICT this was the only place in -simplifycfg where now-dead conditions of replaced terminators weren't being cleaned up). The only other user of this function is -sccp, but I didn't read that thoroughly enough to figure out whether it might be holding pointers to instructions that could be deleted by this.
llvm-svn: 131855
|
| |
|
|
|
|
| |
"stored once" even if its address is compared.
llvm-svn: 131849
|
| |
|
|
|
|
|
| |
causing it to get into infinite loops when it would widen a
load (which can necessarily leave around dead loads).
llvm-svn: 131847
|
| |
|
|
|
|
| |
of the inlinee to the code representing the original function.
llvm-svn: 131838
|
| |
|
|
|
|
| |
consistently.
llvm-svn: 131803
|
| |
|
|
|
|
|
|
| |
add.with.overflow(X, X)"
It's better to do this in codegen, mul.with.overflow(X, 2) is more canonical because it has only one use on "X".
llvm-svn: 131798
|
| |
|
|
|
|
| |
add.with.overflow(X, X)
llvm-svn: 131789
|
| |
|
|
|
|
|
|
|
|
| |
No functionality enabled by default. Use -disable-iv-rewrite.
Extended IVUsers to keep track of the phi that represents the users' IV.
Added the WidenIV transform to replace a narrow IV with a wide IV
by doing a one-for-one replacement of IV users instead of expanding the
SCEV expressions. [sz]exts are removed and truncs are inserted.
llvm-svn: 131744
|
| |
|
|
| |
llvm-svn: 131716
|
| |
|
|
| |
llvm-svn: 131708
|
| |
|
|
| |
llvm-svn: 131673
|
| |
|
|
| |
llvm-svn: 131659
|
| |
|
|
| |
llvm-svn: 131620
|
| |
|
|
|
|
| |
I'm not sure this is quite ideal, but I can't really think of any better way to do it.
llvm-svn: 131616
|
| |
|
|
| |
llvm-svn: 131609
|
| |
|
|
| |
llvm-svn: 131607
|
| |
|
|
| |
llvm-svn: 131605
|
| |
|
|
| |
llvm-svn: 131604
|
| |
|
|
| |
llvm-svn: 131598
|
| |
|
|
| |
llvm-svn: 131596
|
| |
|
|
| |
llvm-svn: 131580
|
| |
|
|
|
|
|
| |
of the comparison, so that the resulting expression is fully
normalized. This fixes PR9939.
llvm-svn: 131576
|
| |
|
|
| |
llvm-svn: 131571
|
| |
|
|
| |
llvm-svn: 131566
|
| |
|
|
| |
llvm-svn: 131561
|
| |
|
|
| |
llvm-svn: 131559
|
| |
|
|
| |
llvm-svn: 131552
|
| |
|
|
| |
llvm-svn: 131551
|
| |
|
|
| |
llvm-svn: 131548
|
| |
|
|
| |
llvm-svn: 131547
|
| |
|
|
| |
llvm-svn: 131545
|
| |
|
|
| |
llvm-svn: 131544
|
| |
|
|
| |
llvm-svn: 131543
|
| |
|
|
| |
llvm-svn: 131542
|
| |
|
|
| |
llvm-svn: 131541
|