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

non-deterministic things like the ordering of blocks in the dominance
frontier of a BB.  Unfortunately, I don't know of a better way to solve
this problem than to explicitly sort the BB's in function-order before
processing them.  This is guaranteed to slow the pass down a bit, but
is absolutely necessary to get usable diffs between two different tools
executing the mem2reg or scalarrepl pass.

Before this, bazillions of spurious diff failures occurred all over the
place due to the different order of processing PHIs:

-       %tmp.111 = getelementptr %struct.Connector_struct* %upcon.0.0, uint 0, uint 0
+       %tmp.111 = getelementptr %struct.Connector_struct* %upcon.0.1, uint 0, uint 0

Now, the diffs match.

llvm-svn: 14244

nondeterministic results that depend on where these objects land in memory.
Instead, sort by the value of the constant, which is stable.

Before this patch, the -simplifycfg pass run from two different compilers
could cause different code to be generated, though it was semantically the
same:

@@ -12258,8 +12258,8 @@
        %s_addr.1 = phi sbyte* [ %s, %entry ], [ %inc.0, %no_exit ]             ; <sbyte*> [#uses=5]
        %tmp.1 = load sbyte* %s_addr.1          ; <sbyte> [#uses=1]
        switch sbyte %tmp.1, label %no_exit [
-                sbyte 0, label %loopexit
                 sbyte 46, label %loopexit
+                sbyte 0, label %loopexit
        ]

We need to stomp all of this stuff out.

llvm-svn: 14243

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

things from happening due to

declare bool %llvm.isunordered(double, double)
declare bool %llvm.isunordered(float, float)

llvm-svn: 14219

llvm-svn: 14206

PR371

llvm-svn: 14203

llvm-svn: 14201

Delete two functions that are now methods on the Type class

llvm-svn: 14200

llvm-svn: 14196

llvm-svn: 14192

llvm-svn: 14186

is write an autoconf macro that checks whether __isnan or isnan actually works
**using the C++ compiler after #include <cmath>**, instead of doing it the easy
way with AC_CHECK_FUNCS().

llvm-svn: 14171

llvm-svn: 14168

llvm-svn: 14150

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

llvm-svn: 13930

llvm-svn: 13872

to eliminate the wrong type.

llvm-svn: 13855