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

This is a regression from 1.2, though noone uses -no-aa anyway

llvm-svn: 14245

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

* Order #includes alphabetically

llvm-svn: 14234

llvm-svn: 14233

llvm-svn: 14231

llvm-svn: 14230

llvm-svn: 14229

using the local & in regs first because they are not clobbered by calls.

llvm-svn: 14228

llvm-svn: 14227

Replace it with a working class for FP instrs.

llvm-svn: 14226

Add some FP moves.

llvm-svn: 14225

Use this for printing the jmpl indirect-call instruction.

llvm-svn: 14224

Support indirect calls.
Support returning a float value.

llvm-svn: 14223

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

Support copying floating-point constants to registers.
Add assertion to visitCallInst to abort if we hit a NULL calledFunction, for now.

llvm-svn: 14216

llvm-svn: 14215

mov REG, C
sub REG, X

generate:

neg X
add X, C

which uses one less reg

llvm-svn: 14213

the setcc.

llvm-svn: 14212

Make copyRegToReg return 1 instead of -1.
Edit a comment in emitPrologue().

llvm-svn: 14211

Add a FIXME about the (currently unused) JMPL instructions.

llvm-svn: 14210

llvm-svn: 14209

modifications for 1 LLVM BB --> many MBBs).
Fix store operand order: make it always be Base, Offset, SrcReg (think
"[ Base + Offset ] = SrcReg").
Rewrite visitBranchInst() to be even dumber (but working) -- give up on
the branch fallthrough trick, for the time being.
Make visitSetCondInst() work.

llvm-svn: 14208

llvm-svn: 14207

llvm-svn: 14206

llvm-svn: 14205

we do not want to fold the load in cases like this:

  X = load
    = add A, X
    = add B, X

llvm-svn: 14204

PR371

llvm-svn: 14203

Abort if we see a PCRelativeDisp MachineOperand, to be safe. This matches
the X86 backend.

llvm-svn: 14202

llvm-svn: 14201

Delete two functions that are now methods on the Type class

llvm-svn: 14200

llvm-svn: 14199

llvm-svn: 14196

The vector may actually be empty if the register that we are marking as
recently used is not actually allocatable.  This happens for physical registers
that are not allocatable, like the ST(x) registers on X86.

llvm-svn: 14195

llvm-svn: 14194