the callgraph.

llvm-svn: 25317

when they change the program

llvm-svn: 25316

llvm-svn: 25315

llvm-svn: 25314

llvm-svn: 25313

llvm-svn: 25312

llvm-svn: 25311

llvm-svn: 25310

llvm-svn: 25309

llvm-svn: 25308

llvm-svn: 25307

testcase for PR676: http://llvm.cs.uiuc.edu/PR676

llvm-svn: 25306

llvm-svn: 25304

llvm-svn: 25303

llvm-svn: 25302

llvm-svn: 25301

llvm-svn: 25300

llvm-svn: 25299

llvm-svn: 25298

llvm-svn: 25297

llvm-svn: 25296

llvm-svn: 25295

llvm-svn: 25294

llvm-svn: 25293

llvm-svn: 25292

llvm-svn: 25291

flipped around.

llvm-svn: 25290

llvm-svn: 25289

InlineFunction handles this case safely.  This implements
Transforms/Inline/dynamic_alloca_test.ll.

llvm-svn: 25288

inlined correctly.

llvm-svn: 25287

resultant code with llvm.stacksave/llvm.stackrestore intrinsics.

llvm-svn: 25286

time in common C cases.

llvm-svn: 25285

it doesn't contain any calls.  This is a fairly common case for C++ code,
so it will probably speed up the inliner marginally in these cases.

llvm-svn: 25284

"HandleInlinedInvoke".  No functionality change.

llvm-svn: 25283

llvm-svn: 25282

code being cloned if the client wants.

llvm-svn: 25281

function was not an alloca, we wouldn't check the entry block for any allocas,
leading to increased stack space in some cases.  In practice, allocas are almost
always at the top of the block, so this was never noticed.

llvm-svn: 25280

llvm-svn: 25279

llvm-svn: 25278

llvm-svn: 25277