case where there are multiple blocks with a large
number of common tail instructions more efficiently
(compile time optimization).

llvm-svn: 50916

clashes on ::X

llvm-svn: 50912

llvm-svn: 50911

llvm-svn: 50910

llvm-svn: 50908

crash on kimwitu++.

llvm-svn: 50901

llvm-svn: 50900

Fixed the build breakage, sorry for that.

llvm-svn: 50895

llvm-svn: 50883

   ~x < ~y --> y < x
   -x == -y --> x == y

llvm-svn: 50882

llvm-svn: 50881

llvm-svn: 50880

llvm-svn: 50878

llvm-svn: 50874

llvm-svn: 50872

llvm-svn: 50871

llvm-svn: 50869

llvm-svn: 50868

llvm-svn: 50867

llvm-svn: 50863

Patch by Matthijs Kooijman!

llvm-svn: 50861

also need to be checked for memory modifying instructions before we
can sink them.  THis fixes the second half of PR2297.

llvm-svn: 50860

delete the first store in:

store x -> p
load p
store y -> p

This is for PR2297.

llvm-svn: 50859

Instruction::mayWriteToMemory stronger for invokes.

llvm-svn: 50858

llvm-svn: 50851

Darwin.  This is a hack of course, but it does
at least look at the right thing: gotpcrel means
that this is already an offset, so an explicit
offset is not needed (and wrong).  I think this
is good enough for the moment: Anton is working
on something better.

llvm-svn: 50850

llvm-svn: 50841

base is not zero.  This fixes test/C++Frontend/2008-05-07-CrazyOffsetOf.cpp

llvm-svn: 50840

Handle vector move / load which zero the destination register top bits (i.e. movd, movq, movss (addr), movsd (addr)) with X86 specific dag combine.

llvm-svn: 50838

llvm-svn: 50837

llvm-svn: 50836

llvm-svn: 50833

llvm-svn: 50828

by an instance of LibCallInfo to provide mod/ref info of
standard library functions.  This is powerful enough to
say that 'sqrt' is readonly except that it modifies errno,
or that "printf doesn't store to memory unless the %n
constraint is present" etc.

llvm-svn: 50827

llvm-svn: 50826

on x86-64 linux.  This causes no regressions on
32 bit linux and 32 bit ppc.  More tests pass
on 64 bit ppc with no regressions.  I didn't
turn on eh on 64 bit linux because the intrinsics
needed to compile the eh runtime aren't done
yet.  But if you turn it on and link with the
mainline runtime then eh seems to work fine
on x86-64 linux with this patch.  Thanks to
Dale for testing.  The main point of the patch
is that if you output that some object is
encoded using 4 bytes you had better not output
8 bytes for it: the patch makes everything
consistent.

llvm-svn: 50825

llvm-svn: 50823

llvm-svn: 50821

Currently is sufficient to describe mod/ref behavior but will hopefully
eventually be extended for other purposes.

This isn't used by anything yet.

llvm-svn: 50820

llvm-svn: 50805