confusion with LSRInstance's RegUses member.

llvm-svn: 104076

inliner did in r103653. Why does the always inliner even bother with cost
estimates anyways?

llvm-svn: 103858

llvm-svn: 103857

llvm-svn: 103700

vector<>::push_back() in:

  int foo(vector<int> &a, vector<unsigned> &b) {
    a.push_back(10);
    b.push_back(11);
  }

to two calls to the same push_back function, or fold away the two copies of
push_back() in:

  struct T { int; };
  struct S { char; };
  vector<T*> t;
  vector<S*> s;
  void f(T *x) { t.push_back(x); }
  void g(S *x) { s.push_back(x); }

but leave f() and g() separate, since they refer to two different global
variables.

llvm-svn: 103698

on RAUW of functions, this is a correctness issue instead of a mere memory
usage problem.


No testcase until the new MergeFunctions can land.

llvm-svn: 103653

to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.

llvm-svn: 103495

llvm-svn: 103457

when it detects undefined behavior.  llvm.trap generally codegens into some
thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this
sort of thing is "nontrivial".  For example, we now compile:

void foo() { *(int*)0 = 42; }

into:

_foo:
	pushl	%ebp
	movl	%esp, %ebp
	ud2

Some may even claim that this is a security hole, though that seems dubious
to me.  This addresses rdar://7958343 - Optimizing away null dereference 
potentially allows arbitrary code execution

llvm-svn: 103356

with a vector input and output into a shuffle vector.  This sort of 
sequence happens when the input code stores with one type and reloads
with another type and then SROA promotes to i96 integers, which make
everyone sad.

This fixes rdar://7896024

llvm-svn: 103354

llvm-svn: 103347

LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.

This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.

Also, add a few asserts to diagnose this kind of situation.

llvm-svn: 103328

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