Stop using memdep for a check that didn't really make sense with memdep. In terms of specific issues, using memdep here checks irrelevant instructions and won't work properly once we start returning "unknown" more aggressively from memdep.

llvm-svn: 133035

Add "unknown" results for memdep, which mean "I don't know whether a dependence for the given instruction exists in the given block".  This cleans up all the existing hacks in memdep which represent this concept by returning clobber with various unrelated instructions.

llvm-svn: 133031

llvm-svn: 132982

llvm-svn: 132952

llvm-svn: 132940

llvm-svn: 132939

llvm-svn: 132938

spartan right now, but I plan to encode more information in this enum to improve
the correctness and reliability of SRoA. At least this first pass makes it
possible to make VectorTy an actual VectorType.

llvm-svn: 132937

llvm-svn: 132936

llvm-svn: 132767

assuming that all offsets are legal vector accesses, and thus trying to access
the float member of { <2 x float>, float } as the 3rd element of the first
member.

llvm-svn: 132766

former was using the size of the entire alloca, whereas the latter was correctly using
the allocated size of the immediate type being converted (which may differ from the size
of the alloca). This fixes PR10082.

llvm-svn: 132759

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

PR10067: Add missing safety check to call return transformation in 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: 132285

code in one place. Re-apply 131534 and fix the multi-step promotion of integers.

llvm-svn: 132217

Attempt to preserve debug line info in LICM; as the comment in the code says, it's hard to pick good line numbers for this transformation, but something is better than nothing.

rdar://9143729

llvm-svn: 132215

Don't sink or hoist debug info instrinsics; it isn't useful.  This also prevents LICM sinking from erasing debug intrinsics which don't dominate any exit block of the loop.

rdar://9143943 .

llvm-svn: 132201

llvm-svn: 132195

llvm-svn: 132194

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

llvm-svn: 132161

If llvm.dbg.value and the value instruction it refers to are far apart then 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: 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

llvm-svn: 131956

promoting allocas to SSA variables. Fixes <rdar://problem/9479036>.

llvm-svn: 131953

This fixes PR9845.

llvm-svn: 131919

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

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

Add a parameter to ConstantFoldTerminator() that callers can use to ask it 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

causing it to get into infinite loops when it would widen a 
load (which can necessarily leave around dead loads).

llvm-svn: 131847

consistently.

llvm-svn: 131803

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