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

Contributed by Vladimir Prus!

llvm-svn: 14399

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

llvm-svn: 14358

llvm-svn: 14262

can go away

llvm-svn: 14254

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

invalidated out from under us.  This bug goes back to revision 1.1: scary.

llvm-svn: 14242

occurs due to unordered comparison macros in math.h

llvm-svn: 14221

Delete two functions that are now methods on the Type class

llvm-svn: 14200

llvm-svn: 14196

186.crafty, fhourstones and 132.ijpeg.

Bugpoint makes really nasty miscompilations embarassingly easy to find.  It
narrowed it down to the instcombiner and this testcase (from fhourstones):

bool %l7153_l4706_htstat_loopentry_2E_4_no_exit_2E_4(int* %i, [32 x int]* %works, int* %tmp.98.out) {
newFuncRoot:
        %tmp.96 = load int* %i          ; <int> [#uses=1]
        %tmp.97 = getelementptr [32 x int]* %works, long 0, int %tmp.96         ; <int*> [#uses=1]
        %tmp.98 = load int* %tmp.97             ; <int> [#uses=2]
        %tmp.99 = load int* %i          ; <int> [#uses=1]
        %tmp.100 = and int %tmp.99, 7           ; <int> [#uses=1]
        %tmp.101 = seteq int %tmp.100, 7                ; <bool> [#uses=2]
        %tmp.102 = cast bool %tmp.101 to int            ; <int> [#uses=0]
        br bool %tmp.101, label %codeRepl4.exitStub, label %codeRepl3.exitStub

codeRepl4.exitStub:             ; preds = %newFuncRoot
        store int %tmp.98, int* %tmp.98.out
        ret bool true

codeRepl3.exitStub:             ; preds = %newFuncRoot
        store int %tmp.98, int* %tmp.98.out
        ret bool false
}

... which only has one combination performed on it:

$ llvm-as < t.ll | opt -instcombine -debug | llvm-dis
IC: Old =       %tmp.101 = seteq int %tmp.100, 7                ; <bool> [#uses=1]
    New =       setne int %tmp.100, 0           ; <bool>:<badref> [#uses=0]
IC: MOD =       br bool %tmp.101, label %codeRepl3.exitStub, label %codeRepl4.exitStub
IC: MOD =       %tmp.97 = getelementptr [32 x int]* %works, uint 0, int %tmp.96         ; <int*> [#uses=1]

It doesn't get much better than this.  :)

llvm-svn: 14109

llvm-svn: 14108

llvm-svn: 14107

llvm-svn: 14095

collapse this:
bool %le(int %A, int %B) {
        %c1 = setgt int %A, %B
        %tmp = select bool %c1, int 1, int 0
        %c2 = setlt int %A, %B
        %result = select bool %c2, int -1, int %tmp
        %c3 = setle int %result, 0
        ret bool %c3
}

into:

bool %le(int %A, int %B) {
        %c3 = setle int %A, %B          ; <bool> [#uses=1]
        ret bool %c3
}

which is handy, because the Java FE makes these sequences all over the place.

This is tested as: test/Regression/Transforms/InstCombine/JavaCompare.ll

llvm-svn: 14086

llvm-svn: 14083

llvm-svn: 13872

This code hadn't been updated after the "structs with more than 256 elements"
related changes to the GEP instruction.  Also it was not handling the
ConstantAggregateZero class.

Now it does!

llvm-svn: 13834

llvm-svn: 13750

llvm-svn: 13749

into (X & (C2 << C1)) != (C3 << C1), where the shift may be either left or
right and the compare may be any one.

This triggers 1546 times in 176.gcc alone, as it is a common pattern that
occurs for bitfield accesses.

llvm-svn: 13740

Canonicalize cast X to bool into a setne instruction

llvm-svn: 13736