previous copy elisions and we discover we need to reload a register, make
sure to use the regclass of the original register for the reload, not the
class of the current register.  This avoid using 16-bit loads to reload 32-bit
values.

llvm-svn: 23645

llvm-svn: 23644

llvm-svn: 23643

llvm-svn: 23642

llvm-svn: 23641

llvm-svn: 23640

llvm-svn: 23639

  store r12 -> [ss#2]
  R3 = load [ss#1]
  use R3
  R3 = load [ss#2]
  R4 = load [ss#1]

and turn it into this code:

  store R12 -> [ss#2]
  R3 = load [ss#1]
  use R3
  R3 = R12
  R4 = R3    <- oops!

The problem was that promoting R3 = load[ss#2] to a copy missed the fact that
the instruction invalidated R3 at that point.

llvm-svn: 23638

llvm-svn: 23637

with the dag combiner.  This speeds up espresso by 8%, reaching performance
parity with the dag-combiner-disabled llc.

llvm-svn: 23636

llvm-svn: 23635

dead node elim and dag combiner passes where the root is potentially updated.
This fixes a fixme in the dag combiner.

llvm-svn: 23634

llvm-svn: 23633

that testcase still does not pass with the dag combiner.  This is because
not all forms of br* are folded yet.

Also, when we combine a node into another one, delete the node immediately
instead of waiting for the node to potentially come up in the future.

llvm-svn: 23632

the second phase of dag combining

llvm-svn: 23631

llvm-svn: 23630

llvm-svn: 23629

When moving constant entries in 'Map' if the entry is the representative
constant for the abstractypemap, make sure to update it as well.  This
fixes the bcreader failures from last night on several C++ apps.

llvm-svn: 23628

of the python test from 1:00 to 54s.

llvm-svn: 23627

true dynamically.  Finally, pass the Use* that replaceAllUsesWith has into
the method for future use.

llvm-svn: 23626

take the bool.  The bool is always true dynamically.

llvm-svn: 23625

creating the keys and doing comparisons to index into 'Map' takes a lot
of time.  For these large constants, keep an inverse map so that 'remove'
and move operations are much faster.

This speeds up a release build of the bc reader on Eric's nasty python
bytecode file from 1:39 to 1:00s.

llvm-svn: 23624

from 1:41 -> 1:39 on the large python .bc file in a release build.

llvm-svn: 23623

llvm-svn: 23622

llvm-svn: 23621

Since calls return more than one value, don't bail if one of their uses
happens to be a node that's not an MVT::Other when following the chain
from CALLSEQ_START to CALLSEQ_END.

Once we've found a CALLSEQ_START, we can just return; there's no need to
tail-recurse further up the graph.

Most importantly, just because something only has one use doesn't mean we
should use it's one use to follow from start to end.  This faulty logic
caused us to follow a chain of one-use FP operations back to a much earlier
call, putting a cycle in the graph from a later start to an earlier end.

This is a better fix that reverting to the workaround committed earlier
today.

llvm-svn: 23620

testcase a bit more from 1:48 -> 1.40.

llvm-svn: 23619

llvm-svn: 23618

Neither of us have yet figured out why this code is necessary, but stuff
breaks if its not there.  Still tracking this down...

llvm-svn: 23617

and more correct than use_empty().  This fixes PR635 and
SimplifyCFG/2005-10-02-InvokeSimplify.ll

llvm-svn: 23616

llvm-svn: 23615

constant arrays in place instead of reallocating them and replaceAllUsesOf'ing
the result.  This speeds up a release build of the bcreader from:

136.987u 120.866s 4:24.38
to
49.790u 49.890s 1:40.14

... a 2.6x speedup parsing a large python bc file.

llvm-svn: 23614

llvm-svn: 23613

llvm-svn: 23612

lookups instead of linear time lookups.  This speeds up bc parsing of a
large file from

137.834u 118.256s 4:27.96
to
132.611u 114.436s 4:08.53

with a release build.

llvm-svn: 23611

llvm-svn: 23610

llvm-svn: 23609

for globals

llvm-svn: 23608

llvm-svn: 23606

llvm-svn: 23605