On Mon, Oct 17, 2011 at 1:31 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2011/10/17 Richard Guenther <richard.guent...@gmail.com>: >> On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz <ktiet...@googlemail.com> wrote: >>> 2011/10/17 Richard Guenther <richard.guent...@gmail.com>: >>>> On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz <ktiet...@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 <kti...@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?
Certainly if for (A TRUTH-IF B) TRUTH-IF C it is valid to associate it as A TRUTH-IF (B IF C) then it is valid to do the same for (A TRUTH-IF B) IF C. > Regards, > Kai >