This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


2011/10/17 Richard Guenther <richard.guenther@gmail.com>:
> On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2011/10/17 Richard Guenther <richard.guenther@gmail.com>:
>>> On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>>> Hello,
>>>>
>>>> So I committed the gimplify patch separate. ?And here is the remaining
>>>> fold-const patch.
>>>> The important tests here are in gcc.dg/tree-ssa/builtin-expect[1-4].c, which
>>>> cover the one special-case for branching. Also tree-ssa/20040204-1.c covers
>>>> tests for branching code (on targets having high-engough BRANCH_COST and no
>>>> special-casing - like MIPS, S/390, and AVR.
>>>>
>>>> ChangeLog
>>>>
>>>> 2011-10-14 ?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?
>>>
>>> Ok with ...
>>>
>>>> Regards,
>>>> Kai
>>>>
>>>> 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);
>>>> ?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
>>>> @@ -3678,7 +3678,7 @@ simple_operand_p (const_tree exp)
>>>> ? STRIP_NOPS (exp);
>>>>
>>>> ? return (CONSTANT_CLASS_P (exp)
>>>> - ? ? ? ? || TREE_CODE (exp) == SSA_NAME
>>>> + ? ? ? ? || TREE_CODE (exp) == SSA_NAME
>>>> ? ? ? ? ?|| (DECL_P (exp)
>>>> ? ? ? ? ? ? ?&& ! TREE_ADDRESSABLE (exp)
>>>> ? ? ? ? ? ? ?&& ! TREE_THIS_VOLATILE (exp)
>>>> @@ -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)));
>>>
>>> recurse with simple_operand_p.
>>
>> No, as this again would reject simple operations and additionally
>> wouldn't check for trapping.
>
> ? ?Your code allows arbitrarily complex expressions. ?Also
> tree_could_trap_p obviously extents to operands.

Ah, ok. I wasn't aware that it walks into tree.

>>
>>>> +
>>>> + ?if (TREE_SIDE_EFFECTS (exp)
>>>> + ? ? ?|| tree_could_trap_p (exp))
>>>
>>> Move this check before the tcc_comparison check and remove the
>>> then redundant tree_could_trap_p check there.
>>
>> Ok
>>
>>>> + ? ?return false;
>>>> +
>>>> + ?switch (code)
>>>> + ? ?{
>>>> + ? ?case SSA_NAME:
>>>> + ? ? ?return true;
>>>
>>> Do not handle here, it's handled in simple_operand_p.
>>
>> Well, was more a short-cut here.
>>
>>>> + ? ?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;
>>>
>>> Remove the BIT_NOT_EXPR handling. ?Thus, simply change this switch
>>> to
>>
>> Why should we reject simple ~X operations from gimplified code here?
>
> Because this is FE triggered code. ?From gimple you won't ever see
> such complex expressions (never even the TRUTH_AND*_EXPR variants).

Hmm, I thought we might see such thing in fold and/or.  But well, you
might be right.

>> I admit that from FE-code we won't see that, as always an integer-cast
>> is done for foo (_Bool x) { ... if (~x) ... }, but from
>> gimplified-code this is the general description of an boolean-typed !=
>> 0?
>>
>>> if (code == TRUTH_NOT_EXPR)
>>> ?return simple_operand_p_2 (TREE_OPERAND (exp, 0));
>>>
>>> return simple_operand_p (exp);
>>>
>>>> + ? ? ?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,49 @@ 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)
>>>> + ? ? ?&& LOGICAL_OP_NON_SHORT_CIRCUIT
>>>> + ? ? ?&& simple_operand_p_2 (arg1))
>>>> + ? ?{
>>>> + ? ? ?enum tree_code ncode = (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR
>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?: TRUTH_OR_EXPR);
>>>> +
>>>> + ? ? ?/* Transform ((A AND-IF B) AND-IF C) into (A AND-IF (B AND C)),
>>>> + ? ? ? ? or ((A OR-IF B) OR-IF C) into (A OR-IF (B OR C))
>>>> + ? ? ? ? We don't want to pack more than two leafs to a 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. ?*/
>>>> + ? ? ? ? && 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);
>>>> + ? ? ? }
>>>
>>> I see you insist on this change. ?Let me explain again. ?You do this
>>> for ((A AND-IF B) AND-IF C) but you don't do this for
>>> ((A AND-IF B) AND C). ?Why? ?That is what doesn't make sense ot me.
>>> Thus omit this hunk.
>>
>> Well, first ((A AND-IF B) AND C) would be an ill sequence, ?as AND is
>> associative. So we would simply break sequence points for && and ||.
>> If left-hand operand is an AND/OR-IF then outer operand has to always
>> an ?-IF operation, too.
>
> Why? ?It's something like (ptr && *ptr) & x. ?Whether you evaluate
> x or (ptr && *ptr) first does not matter. ?But you have to check
> whether ptr is non-null before dereferencing it. ?So it's clearly not
> ill-formed. ?You may argue the transform is pointless and we should
> associate the & instead. ?Do you?

well, if you are explict writing such thing as binary-and, it would be
associative anyway and code doesn't change here anything.  Binary and
!= logical and. The point about if we see something as (A TRUTH-IF B)
TRUTH B), we don't want to change it at all.  The outer if for this
already checks that this operation is just to be used on TRUTH-IF.  To
modify a TRUTH to a TRUTH is pretty point-less, isn't it?  If we would
allow to sink the case (A TRUTH-IF B) TRUTH C to (A TRUTH-IF (B TRUTH
C)), which might be of some intererest, but still would change
association rule here from point of C specification.  By C standard
each ||,&& is treated as a separate sequence-point.  Only in case that
previous and next &&/|| operand have no side-effects, we can apply to
them associative law.  Or do I read C-spec here wrong?

Regards,
Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]