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

move the other block back up into the entry position!

llvm-svn: 60179

llvm-svn: 60166

llvm-svn: 60162

just simple threading.

llvm-svn: 60157

1. Make it fold blocks separated by an unconditional branch.  This enables
   jump threading to see a broader scope.
2. Make jump threading able to eliminate locally redundant loads when they
   feed the branch condition of a block.  This frequently occurs due to
   reg2mem running.
3. Make jump threading able to eliminate *partially redundant* loads when
   they feed the branch condition of a block.  This is common in code with
   lots of loads and stores like C++ code and 255.vortex.

This implements thread-loads.ll and rdar://6402033.

Per the fixme's, several pieces of this should be moved into Transforms/Utils.

llvm-svn: 60148

llvm-svn: 55779

Remove the GetResultInst instruction. It is still accepted in LLVM assembly
and bitcode, where it is now auto-upgraded to ExtractValueInst. Also, remove
support for return instructions with multiple values. These are auto-upgraded
to use InsertValueInst instructions.

The IRBuilder still accepts multiple-value returns, and auto-upgrades them
to InsertValueInst instructions.

llvm-svn: 53941