llvm-svn: 90172

llvm-svn: 90166

llvm-svn: 90165

New virtual registers created for spill intervals should inherit allocation hints from the original register.

This helps us avoid silly copies when rematting values that are copied to a physical register:

leaq	_.str44(%rip), %rcx
movq	%rcx, %rsi
call	_strcmp

becomes:

leaq	_.str44(%rip), %rsi
call	_strcmp

The coalescer will not touch the movq because that would tie down the physical register.

llvm-svn: 90163

branches even when optimizing for code size.  Unless we find evidence to the
contrary in the future, the special treatment for indirect branches does not
have a significant effect on code size, and performance still matters with -Os.

llvm-svn: 90147

for all the processors where I have tried it, and even when it might not help
performance, the cost is quite low.  The opportunities for duplicating
indirect branches are limited by other factors so code size does not change
much due to tail duplicating indirect branches aggressively.

llvm-svn: 90144

llvm-svn: 90141

llvm-svn: 90136

llvm-svn: 90135

llvm-svn: 90134

llvm-svn: 90133

 * Do not SEGFAULT if tree entryNode() is NULL
 * Print function names in dotty printer

llvm-svn: 90130

llvm-gcc build.

llvm-svn: 90113

divide/remainder since these operations can trap by unroll them and adding undefs
for the resulting vector.

llvm-svn: 90108

and reverse nonlocal memdep maps in synch, this should
fix 255.vortex.

llvm-svn: 90107

This permits the devirtualization of llvm.org/PR3100#c9 when compiled by clang.

llvm-svn: 90099

llvm-svn: 90097

    LLVM::Transforms/GVN/2009-02-17-LoadPRECrash.ll
    LLVM::Transforms/GVN/2009-06-17-InvalidPRE.ll

llvm-svn: 90096

was being added to the Result vector, but not being put in the
cache.  This means that if the cache was reused wholesale for a
later query that it would be missing this entry and we'd do an
incorrect load elimination.

Unfortunately, it's not really possible to write a useful 
testcase for this, but this unbreaks 255.vortex.

llvm-svn: 90093

llvm-svn: 90089

llvm-svn: 90085

llvm-svn: 90083

case where realpath() fails. When this occurs we segfault trying to
create a std::string from a NULL pointer.

Fixes PR5635.

llvm-svn: 90082

fix bugs exposed by the tests.  Testcases from Alastair Lynn!

llvm-svn: 90056

llvm-svn: 90050

llvm-svn: 90046

PR5574.

llvm-svn: 90045

handle cases like this:
void test(int N, double* G) {
  long j;
  for (j = 1; j < N - 1; j++)
      G[j+1] = G[j] + G[j+1];
}

where G[1] isn't live into the loop.

llvm-svn: 90041

inserted instructions.  No functionality change until someone starts using it.

llvm-svn: 90039

way that getUnderlyingObject does it. 

This fixes the 'DecomposeGEPExpression and getUnderlyingObject disagree!' 
assertion on sqlite3.

llvm-svn: 90038

if we don't have an address expression available in a predecessor,
then model this as the value being clobbered at the end of the pred
block instead of being modeled as a complete phi translation failure.
This is important for PRE of loads because we want to see that the
load is available in all but this predecessor, and complete phi
translation failure results in not getting any information about
predecessors.

This doesn't do anything until I renable code insertion since PRE
now sees that it is available in all but one predecessors, but can't
insert the addressing in the predecessor that is missing it to 
eliminate the redundancy.

llvm-svn: 90037

to inform GVN about the newly inserted values.  This fixes 
PR5631.

llvm-svn: 90022

fixes PR5630 and sets the stage for the next phase of goodness (testcase
pending).

llvm-svn: 90019

llvm-svn: 90016

for pointing this out.

llvm-svn: 90015

translation of add with immediate.  This allows us
to optimize this function:

void test(int N, double* G) {
  long j;
  G[1] = 1;
    for (j = 1; j < N - 1; j++)
        G[j+1] = G[j] + G[j+1];
}

to only do one load every iteration of the loop.

llvm-svn: 90013

llvm-svn: 90011

llvm-svn: 90009

the FIXME I added yesterday to be implemented.

llvm-svn: 90008

array indexes.  The "complex" case of SRoA still handles them, and correctly.

This fixes a weirdness where we'd correctly avoid transforming A[0][42] if
the 42 was too large, but we'd only do it if it was one gep, not two separate
ones.

llvm-svn: 90007