Speed up SCCP substantially by processing overdefined values quickly.  This
patch speeds up SCCP by about 30-40% on large testcases.

llvm-svn: 14861

This version takes about 1s longer than the previous one (down to 2.35s),
but on the positive side, it actually works :)

llvm-svn: 14856

llvm-svn: 14853

This eliminates an N*N*logN algorithm from the loop simplify pass, replacing
it with a much simpler and faster alternative.  In a debug build, this reduces
gccas time on eon from 85s to 42s.

llvm-svn: 14851

llvm-svn: 14840

llvm-svn: 14839

malloc lowering.  This means that lowerallocations doesn't need targetdata
anymore.  yaay.

llvm-svn: 14835

"load (cast foo)".  This allows us to compile C++ code like this:

class Bclass {
  public: virtual int operator()() { return 666; }
};

class Dclass: public Bclass {
  public: virtual int operator()() { return 667; }
} ;

int main(int argc, char** argv) {
  Dclass x;
  return x();
}

Into this:

int %main(int %argc, sbyte** %argv) {
entry:
        call void %__main( )
        ret int 667
}

Instead of this:

int %main(int %argc, sbyte** %argv) {
entry:
        %x = alloca "struct.std::bad_typeid"            ; <"struct.std::bad_typeid"*> [#uses=3]
        call void %__main( )
        %tmp.1.i.i = getelementptr "struct.std::bad_typeid"* %x, uint 0, uint 0, uint 0         ; <int (...)***> [#uses=1]
        store int (...)** getelementptr ([3 x int (...)*]*  %vtable for Bclass, int 0, long 2), int (...)*** %tmp.1.i.i
        %tmp.3.i = getelementptr "struct.std::bad_typeid"* %x, int 0, uint 0, uint 0            ; <int (...)***> [#uses=1]
        store int (...)** getelementptr ([3 x int (...)*]*  %vtable for Dclass, int 0, long 2), int (...)*** %tmp.3.i
        %tmp.5 = load int ("struct.std::bad_typeid"*)** cast (int (...)** getelementptr ([3 x int (...)*]*  %vtable for Dclass, int 0, long 2) to int
("struct.std::bad_typeid"*)**)          ; <int ("struct.std::bad_typeid"*)*> [#uses=1]
        %tmp.6 = call int %tmp.5( "struct.std::bad_typeid"* %x )                ; <int> [#uses=1]
	ret int %tmp.6
        ret int 0
}

In order words, we now resolve the virtual function call.

llvm-svn: 14783

llvm-svn: 14649

the first is a zero, we should leave it alone.

llvm-svn: 14648

Don't touch GEPs for which DecomposeArrayRef is not going to do anything
special (e.g., < 2 indices, or 2 indices and the last one is a constant.)

llvm-svn: 14647

llvm-svn: 14640

llvm-svn: 14638

Also, remove X % -1 = 0, because it's not true for unsigneds, and the
signed case is superceeded by this new handling.

llvm-svn: 14637

llvm-svn: 14622

llvm-svn: 14587

llvm-svn: 14584

llvm-svn: 14560

llvm-svn: 14541

llvm-svn: 14478

llvm-svn: 14460

and are a maintenence burden.  Nuke nuke nuke

llvm-svn: 14457

llvm-svn: 14443

Contributed by Vladimir Prus!

llvm-svn: 14399

llvm-svn: 14369

Second, disable substitution of quadratic addrec expressions to avoid putting
multiplies in loops!

llvm-svn: 14358

llvm-svn: 14348

llvm-svn: 14340

llvm-svn: 14325

since May 1st.  In this code, the pred iterator was being invalidated sometimes
causing the wrong entries to be added to PHI nodes.

The fix for this is to defererence and safe the *PI value before we hack on
branch instructions, which changes use/def chains, which SOMETIMES invalidates
the iterator.

llvm-svn: 14278

breaking the build on sparc is not acceptable.

llvm-svn: 14277

of ConstantInt objects in memory used to determine which order arguments
were added in in some cases.

llvm-svn: 14276

llvm-svn: 14262

relative location of Function objects in memory.

llvm-svn: 14260

Fix another non-deterministic behavior, this one should actually speed up the
code though as it was doing silly things.

llvm-svn: 14258

can go away

llvm-svn: 14254

into valiantly trying to compile stuff on freebsd.

llvm-svn: 14251

llvm-svn: 14249

was processing blocks in whatever order they happened to end up in the
dominator tree data structure.  Force an ordering.

llvm-svn: 14248

llvm-svn: 14247