Hi,

On Mon, 10 Oct 2011, Kai Tietz wrote:

> To ensure that we use simple_operand_p in all cases, beside for 
> branching AND/OR chains, in same way as before, I added to this function 
> an additional argument, by which the looking into comparisons can be 
> activated.

Better make it a separate function the first tests your new conditions, 
and then calls simple_operand_p.

> +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
> @@ -5149,13 +5176,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;
> -     }

Why do you remove this hunk?  Shouldn't you instead move the hunk you 
added to fold_truth_andor() here.  I realize this needs some TLC to 
fold_truth_andor_1, because right now it early-outs for non-comparisons, 
but it seems the better place.  I.e. somehow move the below code into the 
above branch, with the associated diddling on fold_truth_andor_1 that it 
gets called.

> +  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 (arg1, true))
> +    {
> +      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

Missing continuation of the sentence?

> +         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 (TREE_OPERAND (arg0, 1), true))
> +       {
> +         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 (arg0, true))
> +       return fold_build2_loc (loc, ncode, type, arg0, arg1);
> +    }
> +


Ciao,
Michael.

Reply via email to