llvm-svn: 128535

On x86 we now compile "if (a < 0 && b < 0)" into
	testl	%edi, %esi
	js	IF.THEN

llvm-svn: 128496

Fixes PR9569 and will hopefully make selfhost on ASLR-enabled systems more deterministic.

llvm-svn: 128482

vector types. This helps a lot with inlined functions when using the ARM soft
float ABI. Fixes <rdar://problem/9184212>.

llvm-svn: 128453

llvm-svn: 128413

llvm-svn: 128406

Add some debug output when -instcombine uses RAUW. This can make debug output for those cases much clearer since without this it only showed that the original instruction was removed, not what it was replaced with.

llvm-svn: 128399

the subclass optional data.

llvm-svn: 128388

llvm-svn: 128380

removes one use of X which helps it pass the many hasOneUse() checks.

In my analysis, this turns up very often where X = A >>exact B and that can't be
simplified unless X has one use (except by increasing the lifetime of A which is
generally a performance loss).

llvm-svn: 128373

llvm-svn: 128333

There are two ways that a later store can comletely overlap a previous store:

1. They both start at the same offset, but the earlier store's size is <= the
   later's size, or
2. The earlier store's offset is > the later's offset, but it's offset + size
   doesn't extend past the later's offset + size.

llvm-svn: 128332

llvm-svn: 128331

completely overlaps a previous store, thus mistakenly deleting that store. Check
for this condition.

llvm-svn: 128319

llvm-svn: 128257

affect the generated code.

llvm-svn: 128217

void; it doesn't need to have a void type.

llvm-svn: 128212

llvm-svn: 128211

void return type. This fixes PR9487.

llvm-svn: 128197

llvm-svn: 128196

use it later. I couldn't make a test that hits this with the current code.

llvm-svn: 128195

llvm-svn: 128194

that were hit in practice.

llvm-svn: 128146

llvm-svn: 128068

llvm-svn: 128030

llvm-svn: 127997

As suggested by Nick Lewycky, ignore debugging intrinsics when trying to decide whether a destructor is empty or not.

llvm-svn: 127985

llvm-svn: 127984

Re-apply r127953 with fixes: eliminate empty return block if it has no predecessors; update dominator tree if cfg is modified.

llvm-svn: 127981

llvm-svn: 127976

llvm-svn: 127975

llvm-svn: 127974

Add an optimization to GlobalOpt that eliminates calls to __cxa_atexit, if the function passed is empty.

llvm-svn: 127970

to canonicalize IR", it broke a lot of things.

llvm-svn: 127954

to have single return block (at least getting there) for optimizations. This
is general goodness but it would prevent some tailcall optimizations.
One specific case is code like this:
int f1(void);
int f2(void);
int f3(void);
int f4(void);
int f5(void);
int f6(void);
int foo(int x) {
  switch(x) {
  case 1: return f1();
  case 2: return f2();
  case 3: return f3();
  case 4: return f4();
  case 5: return f5();
  case 6: return f6();
  }
}

=>
LBB0_2:                                 ## %sw.bb
  callq   _f1
  popq    %rbp
  ret
LBB0_3:                                 ## %sw.bb1
  callq   _f2
  popq    %rbp
  ret
LBB0_4:                                 ## %sw.bb3
  callq   _f3
  popq    %rbp
  ret

This patch teaches codegenprep to duplicate returns when the return value
is a phi and where the phi operands are produced by tail calls followed by
an unconditional branch:

sw.bb7:                                           ; preds = %entry
  %call8 = tail call i32 @f5() nounwind
  br label %return
sw.bb9:                                           ; preds = %entry
  %call10 = tail call i32 @f6() nounwind
  br label %return
return:
  %retval.0 = phi i32 [ %call10, %sw.bb9 ], [ %call8, %sw.bb7 ], ... [ 0, %entry ]
  ret i32 %retval.0

This allows codegen to generate better code like this:

LBB0_2:                                 ## %sw.bb
        jmp     _f1                     ## TAILCALL
LBB0_3:                                 ## %sw.bb1
        jmp     _f2                     ## TAILCALL
LBB0_4:                                 ## %sw.bb3
        jmp     _f3                     ## TAILCALL

rdar://9147433

llvm-svn: 127953

If an AllocaInst referred by DbgDeclareInst is used by a LoadInst then the LoadInst should also get a corresponding llvm.dbg.value intrinsic.

llvm-svn: 127924

llvm-svn: 127923

llvm-svn: 127922

llvm-svn: 127842

SCEV may generate expressions composed of multiple pointers, which can
lead to invalid GEP expansion. Until we can teach SCEV to follow strict
pointer rules, make sure no bad GEPs creep into IR.
Fixes rdar://problem/9038671.

llvm-svn: 127839