/bzlib.c:126: warning: string length `1056' is greater than the length `509' ISO
C89 compilers are required to support

llvm-svn: 28602

but for sub, it really does!  Fix fixes a miscompilation of fibheap_cut in
llvmgcc4.

llvm-svn: 28600

llvm-svn: 28599

llvm-svn: 28594

llvm-svn: 28592

change the module in any way and we should enforce that.

llvm-svn: 28588

llvm-svn: 28585

llvm-svn: 28584

llvm-svn: 28582

llvm-svn: 28581

llvm-svn: 28579

llvm-svn: 28578

llvm-svn: 28577

only transform a shufps to pshufd when the first two operands are the same.

llvm-svn: 28575

llvm-svn: 28574

llvm-svn: 28573

llvm-svn: 28572

space will be available, even if the callee isn't varargs.

llvm-svn: 28571

llvm-svn: 28565

llvm-svn: 28564

string. Instead of specifying the length, just specify whether the user
wants a terminating null or not. The default is "true" to retain the same
behavior as previously provided by this function.

llvm-svn: 28562

latency targets, e.g. PPC32.

llvm-svn: 28561

non-deterministic. Returns NULL when it's empty!

llvm-svn: 28560

llvm-svn: 28559

stdout when the output of llvm-as is also written to stdout. We'll have to
fix tcl some other way.

llvm-svn: 28557

Tcl to claim that the program had an error and thus produces errors in
the dejagnu testing when its really just a warning.

llvm-svn: 28556

implementation always added a null byte to the end of the string. It turns
out that this is not always wanted. By adding a length parameter we preserve
this behavior when length==0 (default value) but also allow other lengths
(not null terminated) to be created.

llvm-svn: 28552

llvm-svn: 28551

Fold c2 in (x << c1) | c2 where (c2 < c1)
e.g.
int test(int x) {
  return (x << 3) + 7;
}

This can be codegen'd as:
leal 7(,%eax,8), %eax

llvm-svn: 28550

llvm-svn: 28548

llvm-svn: 28546

uses DSA to make find targets of calls.  It provides a very convinient
interface to DSA results to do things with indirect calls, such as
write a devirtualizer (which I have and may commit one of these days).

llvm-svn: 28545

llvm-svn: 28538

llvm-svn: 28537

llvm-svn: 28534

is now theoretically feature-complete.  It has not, however, been thoroughly
test, and is still considered experimental.

llvm-svn: 28529

other calculations on each individually, rather than trying to delay it and do
them all at the end.

llvm-svn: 28527

the iterated Dominance Frontier of the loop-closure Phi's.  This is the
second phase of the LCSSA pass.  The third phase (coming soon) will be to
update all uses of loop variables to use the loop-closure Phi's instead.

llvm-svn: 28524

ldecod, lencod, and SPASS.

llvm-svn: 28523

makes it so that it constant folds instructions on the fly.  This is good
for several reasons:

0. Many instructions are constant foldable after inlining, particularly if
   inlining a call with constant arguments.
1. Without this, the inliner has to allocate memory for all of the instructions
   that can be constant folded, then a subsequent pass has to delete them.  This
   gets the job done without this extra work.
2. This makes the inliner *pass* a bit more aggressive: in particular, it
   partially solves a phase order issue where the inliner would inline lots
   of code that folds away to nothing, but think that the resultant function
   is big because of this code that will be gone.  Now the code never exists.

This is the first part of a 2-step process.  The second part will be smart
enough to see when this implicit constant folding propagates a constant into
a branch or switch instruction, making CFG edges dead.

This implements Transforms/Inline/inline_constprop.ll

llvm-svn: 28521