llvm-svn: 103295

llvm-svn: 103276

llvm-svn: 103266

as MachineSink, but it isn't constrained by MachineInstr-level details.

llvm-svn: 103257

This fixes the compile-time regressions seen in last night's tests.

llvm-svn: 103118

MachineSSAUpdater to avoid duplicating all the code.

llvm-svn: 103060

indirect branches in all the predecessors.  This avoids unnecessarily
splitting edges in cases where load PRE is not possible anyway.
Thanks to Jakub Staszak for pointing this out.

llvm-svn: 103034

same, now that getConstant has overloads consistent with ConstantInt::get.

llvm-svn: 102965

Patch by Jakub Staszak!

llvm-svn: 102928

other places, killing a valid transformation is not the right
answer.

llvm-svn: 102850

halting analysis, it is illegal to delete a call to a read-only function.
The correct solution is almost certainly to add a "must halt" attribute and
only allow deletions in its presence.

XFAIL the relevant testcase for now.

llvm-svn: 102831

reflect that it includes all inlined calls now, not just
devirtualized ones.

llvm-svn: 102824

that can have a big effect :).  The first is to enable the
iterative SCC passmanager juice that kicks in when the
scc passmgr detects that a function pass has devirtualized
a call.  In this case, it will rerun all the passes it 
manages on the SCC, up to the iteration count limit (4). This
is useful because a function pass may devirualize a call, and
we want the inliner to inline it, or pruneeh to infer stuff
about it, etc.

The second patch is to add *all* call sites to the 
DevirtualizedCalls list the inliner uses.  This list is
about to get renamed, but the jist of this is that the 
inliner now reconsiders *all* inlined call sites as candidates
for further inlining.  The intuition is this that in cases 
like this:

f() { g(1); }     g(int x) { h(x); }

We analyze this bottom up, and may decide that it isn't 
profitable to inline H into G.  Next step, we decide that it is
profitable to inline G into F, and do so, which means that F 
now calls H.  Even though the call from G -> H may not have been
profitable to inline, the call from F -> H may be (in this case
because a constant allows folding etc).

In my spot checks, this doesn't have a big impact on code.  For
example, the LLC output for 252.eon grew from 0.02% (from
317252 to 317308) and 176.gcc actually shrunk by .3% (from 1525612
to 1520964 bytes).  252.eon never iterated in the SCC Passmgr,
176.gcc iterated at most 1 time.

llvm-svn: 102823

that appear due to inlining a callee as candidates for
futher inlining, but a recent patch made it do this if
those call sites were indirect and became direct.

Unfortunately, in bizarre cases (see testcase) doing this
can cause us to infinitely inline mutually recursive
functions into callers not in the cycle.  Fix this by
keeping track of the inline history from which callsite
inline candidates got inlined from.

This shouldn't affect any "real world" code, but is required
for a follow on patch that is coming up next.

llvm-svn: 102822

Radar 7927803

llvm-svn: 102760

to not increase the alignment of globals with an assigned
alignment and section.

llvm-svn: 102476

add a version of createLowerInvokePass that allows the client
to specify whether it wants "expensive" or "cheap" lowering.

Patch by Alex Mac!

llvm-svn: 102402

llvm-svn: 102358

llvm-svn: 102296

that indvars may use, now that indvars is recognizing le and ge loops.

llvm-svn: 102235

the worklist, making them inline candidates.

llvm-svn: 102213

This fixes a bug where calls inlined into an invoke would get
changed into an invoke but the array would keep pointing to
the (now dead) call.  The improved inliner behavior is still
disabled for now.

llvm-svn: 102196

misses an opportunity to fold add operands, but folds them
after LSR has separated them out. This fixes rdar://7886751.

llvm-svn: 102157

llvm-svn: 102153

that appear in the SCC as a result of inlining as candidates
for inlining.  Change this so that it *does* consider call 
sites that change from being indirect to being direct as a
result of inlining.  This allows it to completely 
"devirtualize" the testcase.

llvm-svn: 102146

arguments are handled with a new InlineFunctionInfo class.  This 
makes it easier to extend InlineFunction to return more info in the
future.

llvm-svn: 102137

define void @f3(void (i8*)* %__f) ssp {
entry:
  call void %__f(i8* undef)
  unreachable
}

define void @f4(i8* %this) ssp align 2 {
entry:
  call void @f3(void (i8*)* @f2) ssp
  ret void
}

The inliner is turning the indirect call to %__f into a direct
call to F2.  Make the call graph more precise when this happens.

The inliner doesn't revisit call sites introduced by inlining,
so there isn't an easy way to test for this, but a more precise
callgraph is a good thing.

llvm-svn: 102131

llvm-svn: 102119

GCCAS time for MultiSource/Benchmarks/ASCI_Purple/SMG2000.

llvm-svn: 102009

Rename ValueMapTy as ValueToValueMapTy to clearly indicate that this has no replationship with ADT/ValueMap.

llvm-svn: 101950

llvm-svn: 101949

llvm-svn: 101899

loop unswitch, and use inst simplify instead.  It is more
powerful and less duplication.

llvm-svn: 101874

inst simplify.  No functionality change.

llvm-svn: 101873

condition we're unswitching on.  In this case, don't try to
simplify the second copy of the loop which may be dead or not,
but is probably a constant now.  This fixes PR6879

llvm-svn: 101870

llvm-svn: 101846

Arg promotion was deleting call graph nodes that still had references
from the 'indirect' CGN.  Like the inliner, it should only delete the
function if all references are gone.

llvm-svn: 101845

just ask ScalarEvolution for it on demand. This helps IVUsers be more robust
in the case of expressions changing underneath it. This fixes PR6862.

llvm-svn: 101819

to determine where to place PHIs by iteratively comparing reaching definitions
at each block.  That was just plain wrong.  This version now computes the
dominator tree within the subset of the CFG where PHIs may need to be placed,
and then places the PHIs in the iterated dominance frontier of each definition.
The rest of the patch is mostly the same, with a few more performance
improvements added in.

llvm-svn: 101612

Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.

llvm-svn: 101579