Don't commute i1 ops in reassociation pass.

[gberry]

Summary

If a target uses branches to implement i1 and/or ops, then the order of the and/or operands determines the branch order. Before this change, the reassociate pass would change the operand order according to its ranking algorithm, which does not take into account branch predictability or original user order.

[gberry]

Cleaning up old reviews.

lib/Transforms/Scalar/Reassociate.cpp

   if (!isa<BinaryOperator>(I))
     return;
 
+  // Do not reassociate boolean (i1) expressions.  We want to preserve the
+  // original order of evaluation for short-circuited comparisons that
+  // SimplifyCFG has folded to AND/OR expressions.  If the expression
+  // is not further optimized, it is likely to be transformed back to a
+  // short-circuited form for code gen, and the source order may have been
+  // optimized for the most likely conditions.
+  if (I->getType()->isIntegerTy(1))
+    return;
+
   if (I->getOpcode() == Instruction::Shl && isa<ConstantInt>(I->getOperand(1)))
     // If an operand of this shift is a reassociable multiply, or if the shift
     // is used by a reassociable multiply or add, turn into a multiply.

   if (I->getType()->isFloatingPointTy() && !I->hasUnsafeAlgebra())
     return;
 
-  // Do not reassociate boolean (i1) expressions.  We want to preserve the
-  // original order of evaluation for short-circuited comparisons that
-  // SimplifyCFG has folded to AND/OR expressions.  If the expression
-  // is not further optimized, it is likely to be transformed back to a
-  // short-circuited form for code gen, and the source order may have been
-  // optimized for the most likely conditions.
-  if (I->getType()->isIntegerTy(1))
-    return;
-
   // If this is a subtract instruction which is not already in negate form,
   // see if we can convert it to X+-Y.
   if (I->getOpcode() == Instruction::Sub) {