a zero. This situation arrises in Fortran code with induction variables
that start at 1 instead of 0. This fixes PR7651.

llvm-svn: 108424

This now passes LIT, nighty test, and llvm-gcc bootstrap on my machine.

llvm-svn: 108422

llvm-svn: 108418

llvm-svn: 108417

it *changing* the things it replaces, not just causing them
to drop to null.  There is no functionality change yet, but 
this is required for a subsequent patch.

llvm-svn: 108414

llvm-svn: 108389

Add instcombine transforms to optimize tests of multiple bits of the same value into a single larger comparison.

llvm-svn: 108378

"bonus" instruction to be speculatively executed.  Add a heuristic to
ensure we're not tripping up out-of-order execution by checking that this bonus
instruction only uses values that were already guaranteed to be available.

This allows us to eliminate the short circuit in (x&1)&&(x&2).

llvm-svn: 108351

llvm-svn: 108322

reapply benjamin's instcombine patch, I don't see anything wrong with it and can't repro any problems with a manual self-host.

llvm-svn: 108320

llvm-svn: 108252

by a return that returns a constant, while elsewhere in the function
another return instruction returns a different constant.  This is a
special case of accumulator recursion, so just generalize the existing
logic a bit.

llvm-svn: 108241

llvm-svn: 108153

llvm-svn: 108152

llvm-svn: 108150

llvm-svn: 108148

llvm-svn: 108147

llvm-svn: 108146

llvm-svn: 108145

llvm-svn: 108144

llvm-svn: 108143

llvm-svn: 108142

llvm-svn: 108141

llvm-svn: 108140

llvm-svn: 108139

llvm-svn: 108138

llvm-svn: 108137

instcombine: fold (x & y) | (~x & z) and (x & y) ^ (~x & z) into ((y ^ z) & x) ^ z which is one instruction shorter. (PR6773)

before:
  %and = and i32 %y, %x
  %neg = xor i32 %x, -1
  %and4 = and i32 %z, %neg
  %xor = xor i32 %and4, %and

after:
  %xor1 = xor i32 %z, %y
  %and2 = and i32 %xor1, %x
  %xor = xor i32 %and2, %z

llvm-svn: 108136

llvm-svn: 108135

llvm-svn: 108134

llvm-svn: 108133

llvm-svn: 108132

llvm-svn: 108131

llvm-svn: 108130

by Hans Vandierendonck from PR7605

llvm-svn: 108116

the LHS and RHS of an and/or instruction, don't multiply add
known predecessor values.  This fixes the crash on testcase
from PR7498

llvm-svn: 108114

operation, but the way it's implemented requires the operation to also be
commutative.  So add a check for commutativity (and tweak the corresponding
comments).  This makes no difference in practice since every associative
LLVM instruction is also commutative!  Here's an example to show the need
for commutativity: the accum_recursion.ll testcase calculates the factorial
function.  Before the transformation the result of a call is
  ((((1*1)*2)*3)...)*x
while afterwards it is
  (((1*x)*(x-1))...*2)*1
which clearly requires both associativity and commutativity of * to be equal
to the original.

llvm-svn: 108056

llvm-svn: 107990

llvm-svn: 107984

llvm-svn: 107983