llvm-svn: 123141

perform rounding other than truncation in the IR. Common C code for this
turns into really an LLVM intrinsic call that blocks a lot of further
optimizations.

llvm-svn: 123135

llvm-svn: 123126

llvm-svn: 123116

Also, switch to a more clear 'sink' function with its declaration to
avoid any confusion about 'g'. Thanks for the suggestion Frits.

llvm-svn: 123113

llvm-svn: 123112

llvm-svn: 123111

llvm-svn: 123103

llvm-svn: 123030

llvm-svn: 122978

llvm-svn: 122966

llvm-svn: 122960

InstCombine: If we call llvm.objectsize on a malloc call we can replace it with the size passed to malloc.

llvm-svn: 122959

llvm-svn: 122954

llvm-svn: 122953

llvm-svn: 122700

header for now for memset/memcpy opportunities.  It turns out that loop-rotate
is successfully rotating loops, but *DOESN'T MERGE THE BLOCKS*, turning "for 
loops" into 2 basic block loops that loop-idiom was ignoring.

With this fix, we form many *many* more memcpy and memsets than before, including
on the "history" loops in the viterbi benchmark, which look like this:

        for (j=0; j<MAX_history; ++j) {
          history_new[i][j+1] = history[2*i][j];
        }

Transforming these loops into memcpy's speeds up the viterbi benchmark from
11.98s to 3.55s on my machine.  Woo.

llvm-svn: 122685

llvm-svn: 122676

llvm-svn: 122675

is the wrong hammer for this nail, and is probably right.

llvm-svn: 122661

numbering, in which it considers (for example) "%a = add i32 %x, %y" and
"%b = add i32 %x, %y" to be equal because the operands are equal and the
result of the instructions only depends on the values of the operands.
This has almost no effect (it removes 4 instructions from gcc-as-one-file),
and perhaps slows down compilation: I measured a 0.4% slowdown on the large
gcc-as-one-file testcase, but it wasn't statistically significant.

llvm-svn: 122654

llvm-svn: 122603

Remove/fix invalid README entries. The well thought out strcpy function doesn't return a pointer to the end of the string.

llvm-svn: 122496

This resolves a README entry and technically resolves PR4916,
but we still get poor code for the testcase in that PR because
GVN isn't CSE'ing uadd with add, filed as PR8817.

Previously we got:

_test7:                                 ## @test7
	addq	%rsi, %rdi
	cmpq	%rdi, %rsi
	movl	$42, %eax
	cmovaq	%rsi, %rax
	ret

Now we get:

_test7:                                 ## @test7
	addq	%rsi, %rdi
	movl	$42, %eax
	cmovbq	%rsi, %rax
	ret

llvm-svn: 122182

llvm-svn: 121854

llvm-svn: 121853

llvm-svn: 121850

llvm-svn: 121849

llvm-svn: 121656

(x & 2^n) ? 2^m+C : C

we can offset both arms by C to get the "(x & 2^n) ? 2^m : 0" form, optimize the
select to a shift and apply the offset afterwards.

llvm-svn: 121609

E.g. -5 % 5 is 0 with srem and 1 with urem.

Also addresses Frits van Bommel's comments.

llvm-svn: 120049

This allows to transform the rem in "1 << ((int)x % 8);" to an and.

llvm-svn: 120028

llvm-svn: 119984

This currently only catches the most basic case, a two-case switch, but can be
extended later.

llvm-svn: 119964

llvm-svn: 119925

void a(int x) { if (((1<<x)&8)==0) b(); }

into "x != 3", which occurs over 100 times in 403.gcc but in no
other program in llvm-test.

llvm-svn: 119922

llvm-svn: 119920

llvm-svn: 118806

llvm-svn: 118797

llvm-svn: 118608