llvm-svn: 83756

llvm-svn: 83755

llvm-svn: 83754

DemoteRegToStack.  This makes it more efficient (because it isn't
creating a ton of load/stores that are eventually removed by a later
mem2reg), and more slightly more effective (because those load/stores
don't get in the way of threading).

llvm-svn: 83706

update all the callers.

llvm-svn: 82889

llvm-svn: 80766

llvm-svn: 78948

llvm-svn: 77685

llvm-svn: 77635

llvm-svn: 77494

llvm-svn: 77152

llvm-svn: 77145

Revert the ConstantInt constructors back to their 2.5 forms where possible, thanks to contexts-on-types.  More to come.

llvm-svn: 77011

instead of getAnalysis<TargetData>().

llvm-svn: 76982

llvm-svn: 76702

llvm-svn: 76598

llvm-svn: 75863

llvm-svn: 75703

This started as a small change, I swear.  Unfortunately, lots of things call the [I|F]CmpInst constructors.  Who knew!?

llvm-svn: 75200

llvm-svn: 74878

llvm-svn: 74844

llvm-svn: 74753

This was considering vector intrinsics to have cost 2, but non-vector
intrinsics to have cost 1, which is backward.

llvm-svn: 74698

a key is present in a std::map or DenseMap to use find instead.

llvm-svn: 74676

as if they were multiple uses of the same instruction.  This interacts
well with the existing loadpre that j-t does to open up many new jump
threads earlier.

llvm-svn: 73768

llvm-svn: 73755

llvm-svn: 70872

  ThreadEdge directly.  This shares the code, but is just a refactoring.
* Make JumpThreading compute the set of loop headers and avoid threading
  across them.  This prevents jump threading from forming irreducible 
  loops (goodness) but also prevents it from threading in other cases that
  are beneficial (see the comment above FindFunctionBackedges).

llvm-svn: 70820

llvm-svn: 67064

llvm-svn: 66252

their main routines.  This makes the tools print their argc/argv
commands if they crash.

llvm-svn: 66248

llvm-svn: 62529

jump threading can have bugs, who knew? ;-)

llvm-svn: 61983

jump threading has been shown to only expose problems not
have bugs itself.  I'm sure it's completely bug free! ;-)

llvm-svn: 60725

llvm-svn: 60534

llvm-svn: 60514

1) have it fold "br undef", which does occur with
   surprising frequency as jump threading iterates.
2) teach j-t to delete dead blocks.  This removes the successor
   edges, reducing the in-edges of other blocks, allowing 
   recursive simplification.
3) Fold things like:
     br COND, BBX, BBY
  BBX:
     br COND, BBZ, BBW

   which also happens because jump threading iterates.

llvm-svn: 60470

llvm-svn: 60337

new instructions it simplifies.  Because we're threading jumps on edges
with constants coming in from PHI's, we inherently are exposing a lot more
constants to the new block.  Folding them and deleting dead conditions
allows the cost model in jump threading to be more accurate as it iterates.

llvm-svn: 60327

predecessor is itself.  This doesn't make sense, and this is
a dead infinite loop anyway.

llvm-svn: 60210