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

(X >s -1) ? C1 : C2 and (X <s  0) ? C2 : C1
into ((X >>s 31) & (C2 - C1)) + C1, avoiding the conditional.

This optimization could be extended to take non-const C1 and C2 but we better
stay conservative to avoid code size bloat for now.

for
int sel(int n) {
     return n >= 0 ? 60 : 100;
}

we now generate
  sarl  $31, %edi
  andl  $40, %edi
  leal  60(%rdi), %eax

instead of
  testl %edi, %edi
  movl  $60, %ecx
  movl  $100, %eax
  cmovnsl %ecx, %eax

llvm-svn: 107866

address spaces when SRoA'ing memcpy's.

llvm-svn: 107846

builds to "Release".  The default build is unchanged (optimization on,
assertions on), however it is now called Release+Asserts.  The intent
is that future LLVM releases released via llvm.org will be Release builds
in the new sense, i.e. will have assertions disabled (currently they have
assertions enabled, for a more than 20% slowdown).  This will bring them
in line with MacOS releases, which ship with assertions disabled.  It also
means that "Release" now means the same things in make and cmake builds:
cmake already disables assertions for "Release" builds AFAICS.

llvm-svn: 107758

llvm-svn: 107637

llvm-svn: 107516

have any effect, and second, deleting stores can potentially invalidate
an AliasAnalysis, and there's currently no notification for this.

llvm-svn: 107496

Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this linkage isn't specific to
Objective-C.

For example, the "objc_msgSend_fixup_alloc" symbol is defined like this:

      .globl l_objc_msgSend_fixup_alloc
      .weak_definition l_objc_msgSend_fixup_alloc
      .section __DATA, __objc_msgrefs, coalesced
      .align 3
l_objc_msgSend_fixup_alloc:
       .quad   _objc_msgSend_fixup
       .quad   L_OBJC_METH_VAR_NAME_1

This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".

Currently only supported on Darwin platforms.

llvm-svn: 107433

such a way that debug info for symbols preserved even if symbols are
optimized away by the optimizer. 

Add new special pass to remove debug info for such symbols.

llvm-svn: 107416

llvm-svn: 107412

llvm-svn: 107335

llvm-svn: 107323

llvm-svn: 107278

llvm-svn: 107277

llvm-svn: 107275

llvm-svn: 107273