C99 runtimes don't have exp2).

llvm-svn: 131872

result is non-zero.  Implement an example optimization (PR9814), which allows us to
transform:
  A / ((1 << B) >>u 2)
into:
  A >>u (B-2)

which we compile into:

_divu3:                                 ## @divu3
	leal	-2(%rsi), %ecx
	shrl	%cl, %edi
	movl	%edi, %eax
	ret

instead of:

_divu3:                                 ## @divu3
	movb	%sil, %cl
	movl	$1, %esi
	shll	%cl, %esi
	shrl	$2, %esi
	movl	%edi, %eax
	xorl	%edx, %edx
	divl	%esi, %eax
	ret

llvm-svn: 131860

failing to form a memset, then having to delete it" but my approximation
isn't safe for self recurrent loops.  Instead of doign a hack, just
do it the right way.

llvm-svn: 131858

Add a parameter to ConstantFoldTerminator() that callers can use to ask it to also clean up the condition of any conditional terminator it folds to be unconditional, if that turns the condition into dead code. This just means it calls RecursivelyDeleteTriviallyDeadInstructions() in strategic spots. It defaults to the old behavior.

I also changed -simplifycfg, -jump-threading and -codegenprepare to use this to produce slightly better code without any extra cleanup passes (AFAICT this was the only place in -simplifycfg where now-dead conditions of replaced terminators weren't being cleaned up). The only other user of this function is -sccp, but I didn't read that thoroughly enough to figure out whether it might be holding pointers to instructions that could be deleted by this.

llvm-svn: 131855

"stored once" even if its address is compared.

llvm-svn: 131849

causing it to get into infinite loops when it would widen a 
load (which can necessarily leave around dead loads).

llvm-svn: 131847

llvm-svn: 131846

llvm-svn: 131845

llvm-svn: 131839

of the inlinee to the code representing the original function.

llvm-svn: 131838

llvm-svn: 131831

It's better to do this in codegen, mul.with.overflow(X, 2) is more canonical because it has only one use on "X".

llvm-svn: 131798

llvm-svn: 131789

llvm-svn: 131708

llvm-svn: 131634

llvm-svn: 131621

llvm-svn: 131604

of the comparison, so that the resulting expression is fully
normalized. This fixes PR9939.

llvm-svn: 131576

llvm-svn: 131559

Start trying to make InstCombine preserve more debug info.  The idea here is to set the debug location on the IRBuilder, which will be then right location in most cases.  This should magically give many transformations debug locations, and fixing places which are missing a debug location will usually just means changing the code creating it to use the IRBuilder.

As an example, the change to InstCombineCalls catches a common case where a call to a bitcast of a function is rewritten.

Chris, does this approach look reasonable?

llvm-svn: 131516

llvm-svn: 131452

corrupted when setjmp returns again.

llvm-svn: 131399

llvm-svn: 131363

llvm-svn: 131350

llvm-svn: 131345

rdar://problem/9267970

Patch by Julien Lerouge!

llvm-svn: 131339

often expressed as "x >= y ? x : y", there is a good chance we can extract
the existing "x >= y" from it and use that as a replacement for "max(x,y)==x".

llvm-svn: 131049

llvm-svn: 131002

return the pointer being dereferenced, it returns the pointee, but a call
might return the pointer itself.

llvm-svn: 130979

PR9838: Fix transform introduced in r127064 to not trigger when only one side of the icmp is an exact shift.

llvm-svn: 130954

but according to my super-optimizer there are only two missed simplifications
of -instsimplify kind when compiling bzip2, and this is one of them.  It amuses
me to have bzip2 be perfectly optimized as far as instsimplify goes!

llvm-svn: 130840

max(a,b) >= a -> true.  According to my super-optimizer, these are
by far the most common simplifications (of the -instsimplify kind)
that occur in the testsuite and aren't caught by -std-compile-opts.

llvm-svn: 130780

a vector compare, generate a vector result rather than i1 (and crashing).

llvm-svn: 130706

This automagically provides a transform noticed by my super-optimizer
as occurring quite often: "rem x, (select cond, x, 1)" -> 0.

llvm-svn: 130694

This obviously helps a lot if the division would be turned into a libcall
(think i64 udiv on i386), but div is also one of the few remaining instructions
on modern CPUs that become more expensive when the bitwidth gets bigger.

This also helps register pressure on i386 when dividing chars, divb needs
two 8-bit parts of a 16 bit register as input where divl uses two registers.

int foo(unsigned char a) { return a/10; }
int bar(unsigned char a, unsigned char b) { return a/b; }

compiles into (x86_64)
_foo:
  imull $205, %edi, %eax
  shrl  $11, %eax
  ret
_bar:
  movzbl        %dil, %eax
  divb  %sil, %al
  movzbl        %al, %eax
  ret

llvm-svn: 130615

This folds away silly stuff like (a&255)/1000 -> 0.

llvm-svn: 130614

llvm-svn: 130613

llvm-svn: 130528

llvm-svn: 130527

llvm-svn: 130526