|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | then we don't want to set the destination in the indirect branch to the
destination. This is because the indirect branch needs its destinations to have
had their block addresses taken. This isn't so of the new critical edge that's
split during this process. If it turns out that the destination block has only
one predecessor, and that being a BB with an indirect branch, then it won't be
marked as 'used' and may be removed.
PR10072
llvm-svn: 132638 | 
| | 
| 
| 
| | llvm-svn: 132578 | 
| | 
| 
| 
| 
| 
| 
| | which edge to split by pred/succ pair, which means that we can end up splitting
the wrong edge (by case value) in the switch statement entirely. Fixes PR10031!
llvm-svn: 132535 | 
| | 
| 
| 
| | llvm-svn: 132505 | 
| | 
| 
| 
| 
| 
| | MemCpyOpt::processStore.  If something accesses the dest of the "copy" between the call and the copy, the performCallSlotOptzn transformation is not valid.
llvm-svn: 132485 | 
| | 
| 
| 
| | llvm-svn: 132402 | 
| | 
| 
| 
| 
| 
| 
| | landing pad, forward llvm.eh.resume calls to it instead of turning them
invalidly into invokes.
llvm-svn: 132382 | 
| | 
| 
| 
| | llvm-svn: 132351 | 
| | 
| 
| 
| 
| 
| 
| | sub with a non-constant.  Fix comments, enlarge test case.
rdar://problem/6501862
llvm-svn: 132348 | 
| | 
| 
| 
| 
| 
| | rdar://problem/6501862
llvm-svn: 132316 | 
| | 
| 
| 
| | llvm-svn: 132290 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | variable. Noticed by inspection.
Simulate memset in EvaluateFunction where the target of the memset and the
value we're setting are both the null value. Fixes PR10047!
llvm-svn: 132288 | 
| | 
| 
| 
| | llvm-svn: 132285 | 
| | 
| 
| 
| 
| 
| | fixes self-host.
llvm-svn: 132275 | 
| | 
| 
| 
| 
| 
| 
| 
| | instead.
Fixes PR10040.
llvm-svn: 132254 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | transformed by the inliner into a branch to the enclosing landing pad
(when inlined through an invoke).  If not so optimized, it is lowered
DWARF EH preparation into a call to _Unwind_Resume (or _Unwind_SjLj_Resume
as appropriate).  Its chief advantage is that it takes both the
exception value and the selector value as arguments, meaning that there
is zero effort in recovering these;  however, the frontend is required
to pass these down, which is not actually particularly difficult.
Also document the behavior of landing pads a bit better, and make it
clearer that it's okay that personality functions don't always land at
landing pads.  This is just a fact of life.  Don't write optimizations that
rely on pushing things over an unwind edge.
llvm-svn: 132253 | 
| | 
| 
| 
| 
| 
| | code in one place. Re-apply 131534 and fix the multi-step promotion of integers.
llvm-svn: 132217 | 
| | 
| 
| 
| 
| 
| 
| 
| | says, it's hard to pick good line numbers for this transformation, but something is better than nothing.
rdar://9143729
llvm-svn: 132215 | 
| | 
| 
| 
| 
| 
| 
| 
| | prevents LICM sinking from erasing debug intrinsics which don't dominate any exit block of the loop.
rdar://9143943 .
llvm-svn: 132201 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | - the selector for the landing pad must provide all available information
    about the handlers, filters, and cleanups within that landing pad
  - calls to _Unwind_Resume must be converted to branches to the enclosing
    lpad so as to avoid re-entering the unwinder when the lpad claimed it
    was going to handle the exception in some way
This is quite specific to libUnwind-based unwinding.  In an effort to not
interfere too badly with other unwinders, and with existing hacks in frontends,
this only triggers on _Unwind_Resume (not _Unwind_Resume_or_Rethrow) and does
nothing with selectors if it cannot find a selector call for either lpad.
llvm-svn: 132200 | 
| | 
| 
| 
| | llvm-svn: 132195 | 
| | 
| 
| 
| | llvm-svn: 132194 | 
| | 
| 
| 
| 
| 
| 
| 
| | trying instsimplify on the arm where we know the compared value.
Stuff like "x == y ? y : x&y" now folds into "x&y".
llvm-svn: 132185 | 
| | 
| 
| 
| 
| 
| | question isn't actually in instcombine).
llvm-svn: 132170 | 
| | 
| 
| 
| 
| 
| | InsertNewInstWith, and use setDebugLoc for the cases which can't be easily handled by the automated mechanisms.
llvm-svn: 132167 | 
| | 
| 
| 
| 
| 
| 
| 
| | This looks like it flagged an actual bug. Devang, please review. I added
the parentheses that change behavior, but make the behavior more closely
match commit log's intent.
llvm-svn: 132165 | 
| | 
| 
| 
| | llvm-svn: 132164 | 
| | 
| 
| 
| 
| 
| 
| | crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and
crc64.[8|16|32] have been renamed to .crc32.64.[8|64].
llvm-svn: 132163 | 
| | 
| 
| 
| | llvm-svn: 132161 | 
| | 
| 
| 
| 
| 
| | iSel may not be able to find corresponding Node for llvm.dbg.value during DAG construction. Make iSel's life easier by removing this distance between llvm.dbg.value and its value instruction.
llvm-svn: 132151 | 
| | 
| 
| 
| 
| 
| 
| 
| | Use a proper worklist for use-def traversal without holding onto an
iterator. Now that we process all IV uses, we need complete logic for
resusing existing derived IV defs. See HoistStep.
llvm-svn: 132103 | 
| | 
| 
| 
| | llvm-svn: 132097 | 
| | 
| 
| 
| | 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 |