to the new module.  Patch provided by Nick Lewycky!

llvm-svn: 28349

llvm-svn: 28289

llvm-svn: 28286

Domagoj Babic!

llvm-svn: 28181

nondeterminism being bad) could cause some trivial missed optimizations (dead
phi nodes being left around for later passes to clean up).

With this, llvm-gcc4 now bootstraps and correctly compares.  I don't know
why I never tried to do it before... :)

llvm-svn: 27984

llvm-svn: 27513

llvm-svn: 27478

llvm-svn: 27344

llvm-svn: 27332

llvm-svn: 27161

llvm-svn: 26673

llvm-svn: 26275

can provide work for the outer loop to canonicalize.

This fixes a case that breaks unswitching.

llvm-svn: 26189

block in the appropriate loop nest.

Third time is the charm, right?

llvm-svn: 26187

llvm-svn: 26128

llvm-svn: 26126

llvm-svn: 26121

loops and their subloops.

llvm-svn: 26118

llvm-svn: 26116

llvm-svn: 25633

llvm-svn: 25572

llvm-svn: 25559

llvm-svn: 25509

packed types correctly.

llvm-svn: 25470

library list as well.  This should help bugpoint.

llvm-svn: 25424

llvm-svn: 25407

This patch is an incremental step towards supporting a flat symbol table.
It de-overloads the intrinsic functions by providing type-specific intrinsics
and arranging for automatically upgrading from the old overloaded name to
the new non-overloaded name. Specifically:
  llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64
  llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64
  llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64
  llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64
  llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64
New code should not use the overloaded intrinsic names. Warnings will be
emitted if they are used.

llvm-svn: 25366

llvm.stacksave/restore when it inserts calls to them.

llvm-svn: 25320

llvm-svn: 25309

llvm-svn: 25295

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

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: 25203

llvm-svn: 25181

llvm-svn: 25153

llvm-svn: 24581