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: 131659

I'm not sure this is quite ideal, but I can't really think of any better way to do it.

llvm-svn: 131616

llvm-svn: 131604

llvm-svn: 131596

llvm-svn: 131559

llvm-svn: 131547

llvm-svn: 131544

llvm-svn: 131542

llvm-svn: 131538

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: 131512

rdar://problem/6945110

llvm-svn: 131493

rdar://problem/9267970

Patch by Julien Lerouge!

llvm-svn: 131339

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

llvm-svn: 130954

llvm-svn: 130705

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: 130489

Fixes PR9809.

llvm-svn: 130485

This shouldn't happen in practice because the icmp would be a constant.
Add a check so we don't miscompile code if something goes wrong.

llvm-svn: 130446

llvm-svn: 130428

This happens when GVN widens loads. Part of PR6627.

llvm-svn: 130405

effective in avoiding recomputation of LCSSA form; the widespread
use of instsimplify (which looks through phi nodes) means it was
not preserving LCSSA form anyway; and instcombine is no longer
scheduled in the middle of the loop passes so this doesn't matter
anymore.

llvm-svn: 130301

when X has multiple uses.  This is useful for exposing secondary optimizations,
but the X86 backend isn't ready for this when X has a single use.  For example,
this can disable load folding.

This is inching towards resolving PR6627.

llvm-svn: 130238

llvm-svn: 130237

llvm-svn: 129644

found by code inspection.

llvm-svn: 129641

Luis Felipe Strano Moraes!

llvm-svn: 129558

canonical, and generally leads to better code.  Found while looking at
an article about saturating arithmetic.

llvm-svn: 129545

llvm-svn: 129419

llvm-svn: 129403

Now that we have a first-class way to represent unaligned loads, the unaligned
load intrinsics are superfluous.

First part of <rdar://problem/8460511>.

llvm-svn: 129401

llvm-svn: 129271

space info. We crash with an assert in this case. This change checks that the
address space of the bitcasted pointer is the same as the gep ptr.

llvm-svn: 128884

It's possible to craft an input that hits the recursion limits in a way
that SimplifyDemandedBits doesn't simplify the icmp but ComputeMaskedBits
can infer which bits are zero.

No test case as it depends on too many other things. Fixes PR9609.

llvm-svn: 128777

llvm-svn: 128745