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

llvm-svn: 107981

llvm-svn: 107976

llvm-svn: 107975

llvm-svn: 107974

llvm-svn: 107972

llvm-svn: 107971

llvm-svn: 107969

llvm-svn: 107968

llvm-svn: 107966

llvm-svn: 107965

llvm-svn: 107962