| Message ID | CAEwic4Zbr7+0i-Ej+30dLh=1KddToWQW5crumRZfs5Zdht4KTg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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.
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
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.
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
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.
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);
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; }