llvm-svn: 122574

memsets.  This is still missing one important validity check, but this is enough
to compile stuff like this:

void test0(std::vector<char> &X) {
  for (std::vector<char>::iterator I = X.begin(), E = X.end(); I != E; ++I)
    *I = 0;
}

void test1(std::vector<int> &X) {
  for (long i = 0, e = X.size(); i != e; ++i)
    X[i] = 0x01010101;
}

With:
 $ clang t.cpp -S -o - -O2 -emit-llvm | opt -loop-idiom | opt -O3 | llc 

to:

__Z5test0RSt6vectorIcSaIcEE:            ## @_Z5test0RSt6vectorIcSaIcEE
## BB#0:                                ## %entry
	subq	$8, %rsp
	movq	(%rdi), %rax
	movq	8(%rdi), %rsi
	cmpq	%rsi, %rax
	je	LBB0_2
## BB#1:                                ## %bb.nph
	subq	%rax, %rsi
	movq	%rax, %rdi
	callq	___bzero
LBB0_2:                                 ## %for.end
	addq	$8, %rsp
	ret
...
__Z5test1RSt6vectorIiSaIiEE:            ## @_Z5test1RSt6vectorIiSaIiEE
## BB#0:                                ## %entry
	subq	$8, %rsp
	movq	(%rdi), %rax
	movq	8(%rdi), %rdx
	subq	%rax, %rdx
	cmpq	$4, %rdx
	jb	LBB1_2
## BB#1:                                ## %for.body.preheader
	andq	$-4, %rdx
	movl	$1, %esi
	movq	%rax, %rdi
	callq	_memset
LBB1_2:                                 ## %for.end
	addq	$8, %rsp
	ret

llvm-svn: 122573

llvm-svn: 122572

llvm-svn: 122567

llvm-svn: 122565

llvm-svn: 122563

No functionality yet.

llvm-svn: 122562

llvm-svn: 122561

llvm-svn: 122556

getOrEnforceKnownAlignment function, which simplifies the code
and makes it stronger.

llvm-svn: 122555

llvm-svn: 122554

Fix a thinko pointed out by Frits van Bommel: looking through global variables in isBytewiseValue is not safe.

llvm-svn: 122550

This allows us to compile "int cst[] = {-1, -1, -1};" into
  movl  $-1, 16(%rsp)
  movq  $-1, 8(%rsp)
instead of
  movl  _cst+8(%rip), %eax
  movl  %eax, 16(%rsp)
  movq  _cst(%rip), %rax
  movq  %rax, 8(%rsp)

llvm-svn: 122548

are not the low bits of x, but the bits that WILL be the low bits after the operation completes.

llvm-svn: 122529

pipeline to be caught by instcombine, and it's not feasible to catch them in SimplifyCFG because the
use-lists are in an inconsistent state at the point where it could know that it need to simplify them.
Instead, have CodeGenPrepare look for trivially redundant PHIs as part of its general cleanup effort.

llvm-svn: 122516

llvm-svn: 122462

new gcc warning that complains on self-assignments and
self-initializations.

llvm-svn: 122458

llvm-svn: 122453

if both A op B and A op C simplify.  This fires fairly often but doesn't
make that much difference.  On gcc-as-one-file it removes two "and"s and
turns one branch into a select.

llvm-svn: 122399

instcombine is compared to instsimplify.

llvm-svn: 122397

I still think that LVI should be handling this, but that capability is some ways off in the future,
and this matters for some significant benchmarks.

llvm-svn: 122378

llvm-svn: 122371

llvm-svn: 122362

visit instructions before their uses, since InstructionSimplify does a
better job in that case.  All this prompted by Frits van Bommel.

llvm-svn: 122343

not very important since the pass is only used for testing, but it does make
it more realistic.  Suggested by Frits van Bommel.

llvm-svn: 122336

plenty left though!), in particular for multiplication.

llvm-svn: 122330

llvm-svn: 122265

it could only be tested indirectly, via instcombine, gvn or some other
pass that makes use of InstructionSimplify, which means that testcases
had to be carefully contrived to dance around any other transformations
that that pass did.

llvm-svn: 122264

llvm-svn: 122258

llvm-svn: 122249

Teach InstCombine to merge (icmp ult (X + CA), C1) | (icmp eq X, C2) into (icmp ult (X + CA), C1 + 1) if C2 + CA == C1.

InstCombine creates these so now we compile x == 23 || x == 24 || x == 25 to
  %x.off = add i32 %x, -23
  %1 = icmp ult i32 %x.off, 3
instead of
  %x.off = add i32 %x, -23
  %1 = icmp ult i32 %x.off, 2
  %cmp3 = icmp eq i32 %x, 25
  %ret2 = or i1 %1, %cmp3

llvm-svn: 122248

llvm-svn: 122238

llvm-svn: 122237

to make sure that the reused alloca has sufficient alignment.

llvm-svn: 122236

llvm-svn: 122235

argument.  The generated alloca has to have at least the alignment of the
byval, if not, the client may be making assumptions that the new alloca won't
satisfy.

llvm-svn: 122234

llvm-svn: 122215

llvm-svn: 122204

llvm-svn: 122190

llvm-svn: 122183