llvm-svn: 14266

llvm-svn: 14265

llvm-svn: 14264

by address.  This prevents the resultant SCEV objects from depending on
where in memory other scev objects happen to live.

llvm-svn: 14263

llvm-svn: 14262

before.

llvm-svn: 14261

relative location of Function objects in memory.

llvm-svn: 14260

llvm-svn: 14259

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

llvm-svn: 14258

replacement for getsrcs.sh which now generates too much text to put on a
Linux command line. The approach taken with llvmgrep is to execute a find
command and execute a grep on each file that matches the name pattern. The
arguments to this script are the same as those of egrep. Note that the -H
and -n options to egrep will always be passed so that you always get the
file and line number of matches.

llvm-svn: 14255

can go away

llvm-svn: 14254

on the address of BasicBlock objects in memory.  This eliminates stuff like this:

 Inorder Dominator Tree:
   [1]  %entry
     [2]  %loopentry
-      [3]  %loopexit
       [3]  %no_exit
-        [4]  %endif
         [4]  %then
+        [4]  %endif
+      [3]  %loopexit
       [3]  %return

llvm-svn: 14253

of BasicBlock objects

llvm-svn: 14252

into valiantly trying to compile stuff on freebsd.

llvm-svn: 14251

llvm-svn: 14250

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

(strangely enough) a stable (determinstic) numbering for basic blocks.

llvm-svn: 14246

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

llvm-svn: 14241

llvm-svn: 14240

llvm-svn: 14239

llvm-svn: 14238

llvm-svn: 14237

llvm-svn: 14236

llvm-svn: 14235

* Order #includes alphabetically

llvm-svn: 14234

llvm-svn: 14233

llvm-svn: 14232

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