llvm-svn: 11151

llvm-svn: 11149

llvm-svn: 11148

llvm-svn: 11147

llvm-svn: 11146

llvm-svn: 11145

llvm-svn: 11144

of the virtual register to certain functions.

llvm-svn: 11143

keeps finding more code motion opportunities now that the dominators are correct!

llvm-svn: 11142

slots each. As a concequence they get numbered as 0, 2, 4 and so
on. The first slot is used for operand uses and the second for
defs. Here's an example:

0: A = ...
2: B = ...
4: C = A + B ;; last use of A

The live intervals should look like:

A = [1, 5)
B = [3, x)
C = [5, y)

llvm-svn: 11141

llvm-svn: 11140

llvm-svn: 11139

llvm-svn: 11138

The problem is that the dominator update code didn't "realize" that it's
possible for the newly inserted basic block to dominate anything.  Because
it IS possible, stuff was getting updated wrong.

llvm-svn: 11137

llvm-svn: 11136

access. Rather we only have to do it on the creation of the interval.

llvm-svn: 11135

llvm-svn: 11133

complete rewrite of load-vn will make it a bit faster.  This changes speeds up
the gcse pass (which uses load-vn) from 25.45s to 0.42s on the testcase in
PR209.

I've also verified that this gives the exact same results as the old one.

llvm-svn: 11132

which causes big reindentation.  While I'm at it, I fix the fixme by removing
some dead code.

llvm-svn: 11131

llvm-svn: 11130

llvm-svn: 11129

llvm-svn: 11128

llvm-svn: 11127

llvm-svn: 11126

operand of the instruction and thus simplify the register allocation.

llvm-svn: 11124

llvm-svn: 11123

slightly slower, but I think we can handle it, especially if it means
BytecodeLibs are correctly regenerated.

llvm-svn: 11122

Take away the default iostream argument of createMachineFunctionPrinterPass(),
at Chris's request.

llvm-svn: 11121

at Chris's request.

llvm-svn: 11120

llvm-svn: 11119

  1. Don't scan to the end of alloca instructions in the caller function to
     insert inlined allocas, just insert at the top.  This saves a lot of
     time inlining into functions with a lot of allocas.
  2. Use splice to move the alloca instructions over, instead of remove/insert.
     This allows us to transfer a block at a time, and eliminates a bunch of
     silly symbol table manipulations.

This speeds up the inliner on the testcase in PR209 from 1.73s -> 1.04s (67%)

llvm-svn: 11118

to be the same (IOW they are not two address instructions).

llvm-svn: 11117

and that basic block ends with a return instruction.  In this case, we can just splice
the cloned "body" of the function directly into the source basic block, avoiding a lot
of rearrangement and splitBasicBlock's linear scan over the split block.  This speeds up
the inliner on the testcase in PR209 from 2.3s to 1.7s, a 35% reduction.

llvm-svn: 11116

llvm-svn: 11115

llvm-svn: 11114

llvm-svn: 11113

fails when the basic block points to the function->end.  Instead, require that
the client pass in the function AND the basicblock to insert into.

llvm-svn: 11112

llvm-svn: 11111

half.

llvm-svn: 11110

before we delete the original call site, allowing slight simplifications of
code, but nothing exciting.

llvm-svn: 11109