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);