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/13 Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Oct 13, 2011 at 1:25 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> Hello,
>>
>> this new version addresses the comments from Michael and additional fixes
>> an latent issue shown up by this rewrite in fold-const.
>> On gimplify.c's gimple_boolify we didn't handled the case that operands
>> for TRUTH-expressions need to have same operand-size for transformation to
>> bitwise operation. ?This shows up for Fortran, as here are more then one
>> boolean-kind type with different mode-sizes. ?I added a testcase for this,
>>
>> ChangeLog
>>
>> 2011-10-13 ?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.
>> ? ? ? ?* gimplify.c (gimple_boolify): Take care that for bitwise-binary
>> ? ? ? ?transformation the operands have compatible types.
>>
>> 2011-10-13 ?Kai Tietz ?<ktietz@redhat.com>
>>
>> ? ? ? ?* gfortran.fortran-torture/compile/logical-2.f90: New test.
>>
>> Bootstrapped and regression-tested for all languages plus Ada and
>> Obj-C++ on x86_64-pc-linux-gnu.
>> Ok for apply?
>>
>> 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)));
>> +
>> + ?if (TREE_SIDE_EFFECTS (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,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);
>> + ? ? ? }
>> + ? ? /* Transform (A AND-IF B) into (A AND B), or (A OR-IF B)
>> + ? ? ? ?into (A OR B).
>> + ? ? ? ?For sequence point consistancy, we need to check for trapping, and
>> + ? ? ? ?side-effects. ?*/
>> + ? ? else if (simple_operand_p_2 (arg0))
>> + ? ? ? return fold_build2_loc (loc, ncode, type, arg0, arg1);
>> + ? ?}
>> +
>> ? return NULL_TREE;
>> ?}
>>
>> Index: gcc/gcc/gimplify.c
>> ===================================================================
>> --- gcc.orig/gcc/gimplify.c
>> +++ gcc/gcc/gimplify.c
>> @@ -2804,8 +2804,13 @@ tree
>> ?gimple_boolify (tree expr)
>> ?{
>> ? tree type = TREE_TYPE (expr);
>> + ?tree new_expr_type;
>> ? location_t loc = EXPR_LOCATION (expr);
>>
>> + ?new_expr_type = type;
>> + ?if (TREE_CODE (type) != BOOLEAN_TYPE)
>> + ? ?new_expr_type = boolean_type_node;
>> +
>> ? if (TREE_CODE (expr) == NE_EXPR
>> ? ? ? && TREE_CODE (TREE_OPERAND (expr, 0)) == CALL_EXPR
>> ? ? ? && integer_zerop (TREE_OPERAND (expr, 1)))
>> @@ -2845,11 +2850,26 @@ gimple_boolify (tree expr)
>> ? ? case TRUTH_ORIF_EXPR:
>> ? ? ? /* Also boolify the arguments of truth exprs. ?*/
>> ? ? ? TREE_OPERAND (expr, 1) = gimple_boolify (TREE_OPERAND (expr, 1));
>> - ? ? ?/* FALLTHRU */
>> +
>> + ? ? ?/* Make sure that operand type is compatible to final
>> + ? ? ? ? expression's type. ?*/
>> + ? ? ?if (!useless_type_conversion_p (new_expr_type,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_TYPE (TREE_OPERAND (expr, 1))))
>> + ? ? ? ?TREE_OPERAND (expr, 1) =
>> + ? ? ? ? ?fold_convert_loc (loc, new_expr_type, TREE_OPERAND (expr, 1));
>> +
>> + ? ? ?/* Fall through. ?*/
>>
>> ? ? case TRUTH_NOT_EXPR:
>> ? ? ? TREE_OPERAND (expr, 0) = gimple_boolify (TREE_OPERAND (expr, 0));
>>
>> + ? ? ?/* Make sure that operand type is compatible to final
>> + ? ? ? ? expression's type. ?*/
>> + ? ? ?if (!useless_type_conversion_p (new_expr_type,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_TYPE (TREE_OPERAND (expr, 0))))
>> + ? ? ? ?TREE_OPERAND (expr, 0) =
>> + ? ? ? ? ?fold_convert_loc (loc, new_expr_type, TREE_OPERAND (expr, 0));
>> +
>> ? ? ? /* These expressions always produce boolean results. ?*/
>> ? ? ? if (TREE_CODE (type) != BOOLEAN_TYPE)
>> ? ? ? ?TREE_TYPE (expr) = boolean_type_node;
>
> No, the callers are responsible for this.

Hmm, well, this is a bit inconsistant IMHO and leads to
code-duplications.  Also we need the same check for final expression
type at those places, which makes logical flow a bit harder to read.
The caller of gimple_boolify isn't responsible to check for other
inner expressions operand consistancy, too.  Its current use is more
"please make this expression and its operands boolean-typed".
Well, but if you insists that I duplicate for all places
TRUTH-expressions are boolified that operands match final typel, then
I will do so.

This issue occuress only for TRUTH-stuff from C-tree, as here operands
can have different types than the expression itself.

Regards,
Kai


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