Patchwork [tree-optimization] : Improve handling of conditional-branches on targets with high branch costs

login
register
mail settings
Submitter Kai Tietz
Date Oct. 11, 2011, 1:56 p.m.
Message ID <CAEwic4Zbr7+0i-Ej+30dLh=1KddToWQW5crumRZfs5Zdht4KTg@mail.gmail.com>
Download mbox | patch
Permalink /patch/118984/
State New
Headers show

Comments

Kai Tietz - Oct. 11, 2011, 1:56 p.m.
So updated version for patch.  It creates new simple_operand_p_2
function instead of modifying simple_operand_p function.

ChangeLog

2011-10-11  Kai Tietz  <ktietz@redhat.com>

	* fold-const.c (simple_operand_p_2): New function.
	(fold_truthop): Rename to
	(fold_truth_andor_1): function name.
	Additionally remove branching creation for logical and/or.
	(fold_truth_andor): Handle branching creation for logical and/or here.

Bootstrapped and regression-tested for all languages plus Ada and
Obj-C++ on x86_64-pc-linux-gnu.
Ok for apply?

Regards,
Kai

 static tree extract_muldiv (tree, tree, enum tree_code, tree, bool *);
@@ -3500,7 +3500,7 @@ optimize_bit_field_compare (location_t l
   return lhs;
 }
 
-/* Subroutine for fold_truthop: decode a field reference.
+/* Subroutine for fold_truth_andor_1: decode a field reference.

    If EXP is a comparison reference, we return the innermost reference.

@@ -3668,7 +3668,7 @@ sign_bit_p (tree exp, const_tree val)
   return NULL_TREE;
 }

-/* Subroutine for fold_truthop: determine if an operand is simple enough
+/* Subroutine for fold_truth_andor_1: determine if an operand is simple enough
    to be evaluated unconditionally.  */

 static int
@@ -3692,6 +3692,46 @@ simple_operand_p (const_tree exp)
 		 registers aren't expensive.  */
 	      && (! TREE_STATIC (exp) || DECL_REGISTER (exp))));
 }
+
+/* Subroutine for fold_truth_andor: determine if an operand is simple enough
+   to be evaluated unconditionally.
+   I addition to simple_operand_p, we assume that comparisons and logic-not
+   operations are simple, if their operands are simple, too.  */
+
+static bool
+simple_operand_p_2 (tree exp)
+{
+  enum tree_code code;
+
+  /* Strip any conversions that don't change the machine mode.  */
+  STRIP_NOPS (exp);
+
+  code = TREE_CODE (exp);
+
+  if (TREE_CODE_CLASS (code) == tcc_comparison)
+    return (!tree_could_trap_p (exp)
+	    && simple_operand_p_2 (TREE_OPERAND (exp, 0))
+	    && simple_operand_p_2 (TREE_OPERAND (exp, 1)));
+
+  if (FLOAT_TYPE_P (TREE_TYPE (exp))
+      && tree_could_trap_p (exp))
+    return false;
+
+  switch (code)
+    {
+    case SSA_NAME:
+      return true;
+    case TRUTH_NOT_EXPR:
+      return simple_operand_p_2 (TREE_OPERAND (exp, 0));
+    case BIT_NOT_EXPR:
+      if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE)
+	return false;
+      return simple_operand_p_2 (TREE_OPERAND (exp, 0));
+    default:
+      return simple_operand_p (exp);
+    }
+}
+
 
 /* The following functions are subroutines to fold_range_test and allow it to
    try to change a logical combination of comparisons into a range test.
@@ -4888,7 +4928,7 @@ fold_range_test (location_t loc, enum tr
   return 0;
 }
 
-/* Subroutine for fold_truthop: C is an INTEGER_CST interpreted as a P
+/* Subroutine for fold_truth_andor_1: C is an INTEGER_CST interpreted as a P
    bit value.  Arrange things so the extra bits will be set to zero if and
    only if C is signed-extended to its full width.  If MASK is nonzero,
    it is an INTEGER_CST that should be AND'ed with the extra bits.  */
@@ -5025,8 +5065,8 @@ merge_truthop_with_opposite_arm (locatio
    We return the simplified tree or 0 if no optimization is possible.  */

 static tree
-fold_truthop (location_t loc, enum tree_code code, tree truth_type,
-	      tree lhs, tree rhs)
+fold_truth_andor_1 (location_t loc, enum tree_code code, tree truth_type,
+		    tree lhs, tree rhs)
 {
   /* If this is the "or" of two comparisons, we can do something if
      the comparisons are NE_EXPR.  If this is the "and", we can do something
@@ -5054,8 +5094,6 @@ fold_truthop (location_t loc, enum tree_
   tree lntype, rntype, result;
   HOST_WIDE_INT first_bit, end_bit;
   int volatilep;
-  tree orig_lhs = lhs, orig_rhs = rhs;
-  enum tree_code orig_code = code;

   /* Start by getting the comparison codes.  Fail if anything is volatile.
      If one operand is a BIT_AND_EXPR with the constant one, treat it as if
@@ -5119,8 +5157,7 @@ fold_truthop (location_t loc, enum tree_
   /* If the RHS can be evaluated unconditionally and its operands are
      simple, it wins to evaluate the RHS unconditionally on machines
      with expensive branches.  In this case, this isn't a comparison
-     that can be merged.  Avoid doing this if the RHS is a floating-point
-     comparison since those can trap.  */
+     that can be merged.  */

   if (BRANCH_COST (optimize_function_for_speed_p (cfun),
 		   false) >= 2
@@ -5149,13 +5186,6 @@ fold_truthop (location_t loc, enum tree_
 			   build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
 				   ll_arg, rl_arg),
 			   build_int_cst (TREE_TYPE (ll_arg), 0));
-
-      if (LOGICAL_OP_NON_SHORT_CIRCUIT)
-	{
-	  if (code != orig_code || lhs != orig_lhs || rhs != orig_rhs)
-	    return build2_loc (loc, code, truth_type, lhs, rhs);
-	  return NULL_TREE;
-	}
     }

   /* See if the comparisons can be merged.  Then get all the parameters for
@@ -8380,13 +8410,47 @@ fold_truth_andor (location_t loc, enum t
      lhs is another similar operation, try to merge its rhs with our
      rhs.  Then try to merge our lhs and rhs.  */
   if (TREE_CODE (arg0) == code
-      && 0 != (tem = fold_truthop (loc, code, type,
-				   TREE_OPERAND (arg0, 1), arg1)))
+      && 0 != (tem = fold_truth_andor_1 (loc, code, type,
+					 TREE_OPERAND (arg0, 1), arg1)))
     return fold_build2_loc (loc, code, type, TREE_OPERAND (arg0, 0), tem);

-  if ((tem = fold_truthop (loc, code, type, arg0, arg1)) != 0)
+  if ((tem = fold_truth_andor_1 (loc, code, type, arg0, arg1)) != 0)
     return tem;

+  if ((code == TRUTH_ANDIF_EXPR || code == TRUTH_ORIF_EXPR)
+      && (BRANCH_COST (optimize_function_for_speed_p (cfun),
+		       false) >= 2)
+      && !TREE_SIDE_EFFECTS (arg1)
+      && LOGICAL_OP_NON_SHORT_CIRCUIT
+      && simple_operand_p_2 (arg1))
+    {
+      enum tree_code ncode = (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR
+						       : TRUTH_OR_EXPR);
+
+      /* We don't want to pack more then two leafs to an non-IF AND/OR
+         expression.
+         If tree-code of left-hand operand isn't an AND/OR-IF code and not
+         equal to CODE, then we don't want to add right-hand operand.
+         If the inner right-hand side of left-hand operand has side-effects,
+         or isn't simple, then we can't add to it, as otherwise we might
+         destroy if-sequence.  */
+      if (TREE_CODE (arg0) == code
+      	  /* Needed for sequence points to handle trappings, and
+      	     side-effects.  */
+      	  && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1))
+      	  && simple_operand_p_2 (TREE_OPERAND (arg0, 1)))
+       {
+         tem = fold_build2_loc (loc, ncode, type, TREE_OPERAND (arg0, 1),
+				arg1);
+         return fold_build2_loc (loc, code, type, TREE_OPERAND (arg0, 0),
+				 tem);
+       }
+     /* Needed for sequence points to handle trappings, and side-effects.  */
+     else if (!TREE_SIDE_EFFECTS (arg0)
+	      && simple_operand_p_2 (arg0))
+       return fold_build2_loc (loc, ncode, type, arg0, arg1);
+    }
+
   return NULL_TREE;
 }
Michael Matz - Oct. 11, 2011, 3:14 p.m.
Hi,

On Tue, 11 Oct 2011, Kai Tietz wrote:

> So updated version for patch.  It creates new simple_operand_p_2
> function instead of modifying simple_operand_p function.

FWIW: I also can't think of a nice short name for that predicate function 
:)  One thing: move the test for TREE_SIDE_EFFECTS to that new function, 
then the if()s in fold_truth_andor become nicer.  I think the code then is 
okay, but I can't approve.  Just one remark about the comment:

> +      /* We don't want to pack more then two leafs to an non-IF AND/OR

s/then/than/ s/an/a/

> +         expression.
> +         If tree-code of left-hand operand isn't an AND/OR-IF code and not
> +         equal to CODE, then we don't want to add right-hand operand.
> +         If the inner right-hand side of left-hand operand has side-effects,
> +         or isn't simple, then we can't add to it, as otherwise we might
> +         destroy if-sequence.  */

And I think it could use some overview of the transformation done like in 
the initial patch, ala:

"Transform ((A && B) && C) into (A && (B & C))."

and

"Or (A && B) into (A & B)." for this part:

+     /* Needed for sequence points to handle trappings, and side-effects.  */
+     else if (simple_operand_p_2 (arg0))
+       return fold_build2_loc (loc, ncode, type, arg0, arg1);


Ciao,
Michael.
Kai Tietz - Oct. 12, 2011, 10:03 a.m.
2011/10/11 Michael Matz <matz@suse.de>:
> Hi,
>
> On Tue, 11 Oct 2011, Kai Tietz wrote:
>
>> So updated version for patch.  It creates new simple_operand_p_2
>> function instead of modifying simple_operand_p function.
>
> FWIW: I also can't think of a nice short name for that predicate function
> :)  One thing: move the test for TREE_SIDE_EFFECTS to that new function,
> then the if()s in fold_truth_andor become nicer.  I think the code then is
> okay, but I can't approve.  Just one remark about the comment:
>
>> +      /* We don't want to pack more then two leafs to an non-IF AND/OR
>
> s/then/than/ s/an/a/

Ok, thanks

>> +         expression.
>> +         If tree-code of left-hand operand isn't an AND/OR-IF code and not
>> +         equal to CODE, then we don't want to add right-hand operand.
>> +         If the inner right-hand side of left-hand operand has side-effects,
>> +         or isn't simple, then we can't add to it, as otherwise we might
>> +         destroy if-sequence.  */
>
> And I think it could use some overview of the transformation done like in
> the initial patch, ala:
>
> "Transform ((A && B) && C) into (A && (B & C))."
>
> and
>
> "Or (A && B) into (A & B)." for this part:
>
> +     /* Needed for sequence points to handle trappings, and side-effects.  */
> +     else if (simple_operand_p_2 (arg0))
> +       return fold_build2_loc (loc, ncode, type, arg0, arg1);
>
>
> Ciao,
> Michael.

Well to use here binary form of operation seems to me misleading.  It
is right that the non-IF AND/OR has finally the same behavior as the
binary form in gimple.  Nevertheless it isn't the same on AST level.
But sure I can Add comments for operations like
(A OR/AND-IF B) OR/AND-IF C -> (A OR/AND-IF (B OR/AND C
and A OR/AND-IF C -> (A OR/AND C)

Is the patch with those changes ok for apply?

Regards,
Kai
Michael Matz - Oct. 12, 2011, 11:57 a.m.
Hi,

On Wed, 12 Oct 2011, Kai Tietz wrote:

> > And I think it could use some overview of the transformation done like in
> > the initial patch, ala:
> >
> > "Transform ((A && B) && C) into (A && (B & C))."
> >
> > and
> >
> > "Or (A && B) into (A & B)." for this part:
> >
> > +     /* Needed for sequence points to handle trappings, and side-effects.  */
> > +     else if (simple_operand_p_2 (arg0))
> > +       return fold_build2_loc (loc, ncode, type, arg0, arg1);
> 
> Well to use here binary form of operation seems to me misleading.

Hmm?  What do you mean?  Both operations are binary.  ANDIF is '&&', AND 
is '&'.  In fold-const.c comments we usually use the C notations of the 
operations.

> It is right that the non-IF AND/OR has finally the same behavior as the 
> binary form in gimple.  Nevertheless it isn't the same on AST level. But 
> sure I can Add comments for operations like (A OR/AND-IF B) OR/AND-IF C 
> -> (A OR/AND-IF (B OR/AND C and A OR/AND-IF C -> (A OR/AND C)

Too much noise, leave out the || variant, and just say once "Same for ||."


Ciao,
Michael.
Kai Tietz - Oct. 12, 2011, 12:05 p.m.
2011/10/12 Michael Matz <matz@suse.de>:
> Hi,
>
> On Wed, 12 Oct 2011, Kai Tietz wrote:
>
>> > And I think it could use some overview of the transformation done like in
>> > the initial patch, ala:
>> >
>> > "Transform ((A && B) && C) into (A && (B & C))."
>> >
>> > and
>> >
>> > "Or (A && B) into (A & B)." for this part:
>> >
>> > +     /* Needed for sequence points to handle trappings, and side-effects.  */
>> > +     else if (simple_operand_p_2 (arg0))
>> > +       return fold_build2_loc (loc, ncode, type, arg0, arg1);
>>
>> Well to use here binary form of operation seems to me misleading.
>
> Hmm?  What do you mean?  Both operations are binary.  ANDIF is '&&', AND
> is '&'.  In fold-const.c comments we usually use the C notations of the
> operations.

See TRUTH_AND_EXPR is in C-notation && and TRUTH_ANDIF_EXPR is also
&&.  The transcription to binary & is done in gimplifier.  Btw I just
noticed that by this patch a latent bug in gimplifier about
boolification for TRUTH_NOT_EXPR/TRUTH_AND/OR... is present.
On Fortran there are different boolean-kinds types with different
precision.  This makes them incompatible to eachother in gimple (as
useless_type_conversion_p returns for them false).  For gimplier needs
to ensure that operands for those TRUTH_... expression met a
compatible type of final expression type.

I will sent a patch for this as soon I completed regression-testing for it.

>> It is right that the non-IF AND/OR has finally the same behavior as the
>> binary form in gimple.  Nevertheless it isn't the same on AST level. But
>> sure I can Add comments for operations like (A OR/AND-IF B) OR/AND-IF C
>> -> (A OR/AND-IF (B OR/AND C and A OR/AND-IF C -> (A OR/AND C)
>
> Too much noise, leave out the || variant, and just say once "Same for ||."
>
>
> Ciao,
> Michael.

Cheers,
Kai
Michael Matz - Oct. 12, 2011, 12:28 p.m.
Hi,

On Wed, 12 Oct 2011, Kai Tietz wrote:

> > Hmm?  What do you mean?  Both operations are binary.  ANDIF is '&&', AND
> > is '&'.  In fold-const.c comments we usually use the C notations of the
> > operations.
> 
> See TRUTH_AND_EXPR is in C-notation && and TRUTH_ANDIF_EXPR is also
> &&.

Ah right, confusing but there we are.  A comment using ANDIF and AND it is 
then.


Ciao,
Michael.

Patch

Index: gcc/gcc/fold-const.c
===================================================================
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -112,13 +112,13 @@  static tree decode_field_reference (loca
 static int all_ones_mask_p (const_tree, int);
 static tree sign_bit_p (tree, const_tree);
 static int simple_operand_p (const_tree);
+static bool simple_operand_p_2 (tree);
 static tree range_binop (enum tree_code, tree, tree, int, tree, int);
 static tree range_predecessor (tree);
 static tree range_successor (tree);
 static tree fold_range_test (location_t, enum tree_code, tree, tree, tree);
 static tree fold_cond_expr_with_comparison (location_t, tree, tree,
tree, tree);
 static tree unextend (tree, int, int, tree);
-static tree fold_truthop (location_t, enum tree_code, tree, tree, tree);
 static tree optimize_minmax_comparison (location_t, enum tree_code,
 					tree, tree, tree);