llvm-svn: 14298

llvm-svn: 14297

* Doxygenify function comments
* Wrap code at 80 cols

llvm-svn: 14295

llvm-svn: 14294

llvm-svn: 14292

Intrinsic::isunordered has arrived, and we just use the standard lowering
pass for it.

llvm-svn: 14290

llvm-svn: 14289

llvm-svn: 14288

llvm-svn: 14287

llvm-svn: 14283

existing llvm::Interval class.

Patch contributed by Vladimir Prus!
http://mail.cs.uiuc.edu/pipermail/llvmbugs/2004-June/000710.html

llvm-svn: 14281

code.  Patch contributed by Vladimir Prus.

llvm-svn: 14280

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

llvm-svn: 14270

llvm-svn: 14269

llvm-svn: 14266

llvm-svn: 14265

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

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

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

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