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

llvm-svn: 13702

llvm-svn: 13690

llvm-svn: 13689

that do not have builtin support for garbage collection.

llvm-svn: 13688

llvm-svn: 13565

in the size calculation.

This is not something you want to see:
Loop Unroll: F[main] Loop %no_exit Loop Size = 2 Trip Count = 2147483648 - UNROLLING!

The problem was that 2*2147483648 == 0.

Now we get:
Loop Unroll: F[main] Loop %no_exit Loop Size = 2 Trip Count = 2147483648 - TOO LARGE: 4294967296>100

Thanks to some anonymous person playing with the demo page that repeatedly
caused zion to go into swapping land.  That's one way to ensure you'll get
a quick bugfix.  :)

Testcase here: Transforms/LoopUnroll/2004-05-13-DontUnrollTooMuch.ll

llvm-svn: 13564

llvm-svn: 13429

        %tmp.0 = getelementptr [50 x sbyte]* %ar, uint 0, int 5         ; <sbyte*> [#uses=2]
        %tmp.7 = getelementptr sbyte* %tmp.0, int 8             ; <sbyte*> [#uses=1]

together.  This patch actually allows us to simplify and generalize the code.

llvm-svn: 13415

llvm-svn: 13400

This fixes PR332 and ADCE/2004-05-04-UnreachableBlock.llx

llvm-svn: 13349

llvm-svn: 13341

missing opportunities for combination.

llvm-svn: 13309

when replacing them, missing the opportunity to do simplifications

llvm-svn: 13308

is only used by a cast, and the casted type is the same size as the original
allocation, it would eliminate the cast by folding it into the allocation.

Unfortunately, it was placing the new allocation instruction right before
the cast, which could pull (for example) alloca instructions into the body
of a function.  This turns statically allocatable allocas into expensive
dynamically allocated allocas, which is bad bad bad.

This fixes the problem by placing the new allocation instruction at the same
place the old one was, duh. :)

llvm-svn: 13289

patch was graciously contributed by Vladimir Prus.

llvm-svn: 13185

llvm-svn: 13172