| Message ID | CAEwic4bRXG6gXi+MWxAN8W_4bECOmXwOUngG6FZ+F=7j-kLb=g@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
2011/10/7 Kai Tietz <ktietz70@googlemail.com>: > Hello, > > this is the updated version with the suggestion > > 2011/10/7 Richard Guenther <richard.guenther@gmail.com>: >> On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz <ktietz@redhat.com> wrote: >>> + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison >>> + && TREE_CODE (arg1) != TRUTH_NOT_EXPR >>> + && simple_operand_p (arg1)) >> >> As I said previously simple_operand_p already rejects covers >> comparisons and TRUTH_NOT_EXPR. Also arg1 had better >> TREE_SIDE_EFFECTS set if the comparison might trap, as >> it might just be hidden in something more complicated - so >> the simple check isn't enough anyway (and if simple_operand_p >> would cover it, the check would be better placed there). > > I reworked simple_operand_p so that it does this special-casing and additionally > also checks for trapping. > >>> + if (TREE_CODE (arg0) == code >>> + && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1)) >>> + && simple_operand_p (TREE_OPERAND (arg0, 1))) >>> + { >>> + tem = build2_loc (loc, >>> + (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR >>> + : TRUTH_OR_EXPR), >>> + type, TREE_OPERAND (arg0, 1), arg1); >>> + return build2_loc (loc, code, type, TREE_OPERAND (arg0, 0), >>> + tem); >> >> All trees should be folded, don't use plain build without a good reason. > > Ok, done > >>> + } >>> + /* Convert X TRUTH-ANDORIF Y to X TRUTH-ANDOR Y, if X and Y >>> + are simple operands and have no side-effects. */ >>> + if (simple_operand_p (arg0) >>> + && !TREE_SIDE_EFFECTS (arg0)) >> >> Again, the checks you do for arg0 do not match those for arg1. OTOH >> it doesn't matter whether arg0 is simple or not or has side-effects or >> not for this transformation, so why check it at all? > > It is required. For left-hand operand, if it isn't a logical > and/or/xor, we need to check for side-effects (and for trapping). I > see that calling of simple_operand_p is wrong here, as it rejects too > much. Nevertheless the check for side-effects is necessary for having > valid sequence-points. Without that checking a simple test So said, it is even required to use for right-hand and left-hand side of arguments, if one of them have side-effects or isn't simple. Means the check in my patch should use for > + else if (TREE_CODE (arg0) != TRUTH_AND_EXPR > + && TREE_CODE (arg0) != TRUTH_OR_EXPR > + && TREE_CODE (arg0) != TRUTH_ANDIF_EXPR > + && TREE_CODE (arg0) != TRUTH_ORIF_EXPR > + && TREE_CODE (arg0) != TRUTH_XOR_EXPR > + /* Needed for sequence points and trappings, or side-effects. */ > + && !TREE_SIDE_EFFECTS (arg0) > + && !tree_could_trap_p (arg0)) > + return fold_build2_loc (loc, ncode, type, arg0, arg1); instead if (!TREE_SIDE_EFFECTS (arg0) && simple_operand_p (arg0)) .... instead. The cause for this are the consitancies of sequences in tree. I noticed that by tests in gcc.dg/tree-ssa about builitin_expect. for example we have extern int foo (void); /* foo modifies gbl1 */ int gbl1 = 0; int foo (int ns1) { if (ns1 && foo () && gbl1) return 1; return 0; } so chain of trees has to look like this: (ANDIF (ns1 (ANDIF foo () gbl1)) but if we don't check here for side-effects for left-hand chaining operand, then we end up with (AND ns1 (ANDIF foo () gbl1)) As AND and has associative property, tree says that right-hand and left-hand are exchangable, which is obviously wrong. Cheers, Kai
On Mon, Oct 10, 2011 at 12:35 PM, Kai Tietz <ktietz70@googlemail.com> wrote: > 2011/10/7 Kai Tietz <ktietz70@googlemail.com>: >> Hello, >> >> this is the updated version with the suggestion >> >> 2011/10/7 Richard Guenther <richard.guenther@gmail.com>: >>> On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz <ktietz@redhat.com> wrote: >>>> + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison >>>> + && TREE_CODE (arg1) != TRUTH_NOT_EXPR >>>> + && simple_operand_p (arg1)) >>> >>> As I said previously simple_operand_p already rejects covers >>> comparisons and TRUTH_NOT_EXPR. Also arg1 had better >>> TREE_SIDE_EFFECTS set if the comparison might trap, as >>> it might just be hidden in something more complicated - so >>> the simple check isn't enough anyway (and if simple_operand_p >>> would cover it, the check would be better placed there). >> >> I reworked simple_operand_p so that it does this special-casing and additionally >> also checks for trapping. >> >>>> + if (TREE_CODE (arg0) == code >>>> + && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1)) >>>> + && simple_operand_p (TREE_OPERAND (arg0, 1))) >>>> + { >>>> + tem = build2_loc (loc, >>>> + (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR >>>> + : TRUTH_OR_EXPR), >>>> + type, TREE_OPERAND (arg0, 1), arg1); >>>> + return build2_loc (loc, code, type, TREE_OPERAND (arg0, 0), >>>> + tem); >>> >>> All trees should be folded, don't use plain build without a good reason. >> >> Ok, done >> >>>> + } >>>> + /* Convert X TRUTH-ANDORIF Y to X TRUTH-ANDOR Y, if X and Y >>>> + are simple operands and have no side-effects. */ >>>> + if (simple_operand_p (arg0) >>>> + && !TREE_SIDE_EFFECTS (arg0)) >>> >>> Again, the checks you do for arg0 do not match those for arg1. OTOH >>> it doesn't matter whether arg0 is simple or not or has side-effects or >>> not for this transformation, so why check it at all? >> >> It is required. For left-hand operand, if it isn't a logical >> and/or/xor, we need to check for side-effects (and for trapping). I >> see that calling of simple_operand_p is wrong here, as it rejects too >> much. Nevertheless the check for side-effects is necessary for having >> valid sequence-points. Without that checking a simple test > > So said, it is even required to use for right-hand and left-hand side > of arguments, if one of them have side-effects or isn't simple. Means > the check in my patch should use for > >> + else if (TREE_CODE (arg0) != TRUTH_AND_EXPR >> + && TREE_CODE (arg0) != TRUTH_OR_EXPR >> + && TREE_CODE (arg0) != TRUTH_ANDIF_EXPR >> + && TREE_CODE (arg0) != TRUTH_ORIF_EXPR >> + && TREE_CODE (arg0) != TRUTH_XOR_EXPR >> + /* Needed for sequence points and trappings, or side-effects. */ >> + && !TREE_SIDE_EFFECTS (arg0) >> + && !tree_could_trap_p (arg0)) >> + return fold_build2_loc (loc, ncode, type, arg0, arg1); > > instead if (!TREE_SIDE_EFFECTS (arg0) && simple_operand_p (arg0)) .... > instead. > > The cause for this are the consitancies of sequences in tree. I > noticed that by tests in gcc.dg/tree-ssa about builitin_expect. > > for example we have > > extern int foo (void); /* foo modifies gbl1 */ > int gbl1 = 0; > > int foo (int ns1) > { > if (ns1 && foo () && gbl1) > return 1; > return 0; > } > > so chain of trees has to look like this: > (ANDIF (ns1 (ANDIF foo () gbl1)) > > but if we don't check here for side-effects for left-hand chaining > operand, then we end up with > (AND ns1 (ANDIF foo () gbl1)) No we don't, as the right-hand (ANDIF foo () glbl1) has side-effects. > As AND and has associative property, tree says that right-hand and > left-hand are exchangable, which is obviously wrong. The poitn is that if the right-hand does not have side-effects it doesn't matter if we execute it before the left-hand (independent on whether that has side-effects or not). Richard. > Cheers, > Kai >
2011/10/10 Richard Guenther <richard.guenther@gmail.com>: > On Mon, Oct 10, 2011 at 12:35 PM, Kai Tietz <ktietz70@googlemail.com> wrote: >> 2011/10/7 Kai Tietz <ktietz70@googlemail.com>: >>> Hello, >>> >>> this is the updated version with the suggestion >>> >>> 2011/10/7 Richard Guenther <richard.guenther@gmail.com>: >>>> On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz <ktietz@redhat.com> wrote: >>>>> + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison >>>>> + && TREE_CODE (arg1) != TRUTH_NOT_EXPR >>>>> + && simple_operand_p (arg1)) >>>> >>>> As I said previously simple_operand_p already rejects covers >>>> comparisons and TRUTH_NOT_EXPR. Also arg1 had better >>>> TREE_SIDE_EFFECTS set if the comparison might trap, as >>>> it might just be hidden in something more complicated - so >>>> the simple check isn't enough anyway (and if simple_operand_p >>>> would cover it, the check would be better placed there). >>> >>> I reworked simple_operand_p so that it does this special-casing and additionally >>> also checks for trapping. >>> >>>>> + if (TREE_CODE (arg0) == code >>>>> + && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1)) >>>>> + && simple_operand_p (TREE_OPERAND (arg0, 1))) >>>>> + { >>>>> + tem = build2_loc (loc, >>>>> + (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR >>>>> + : TRUTH_OR_EXPR), >>>>> + type, TREE_OPERAND (arg0, 1), arg1); >>>>> + return build2_loc (loc, code, type, TREE_OPERAND (arg0, 0), >>>>> + tem); >>>> >>>> All trees should be folded, don't use plain build without a good reason. >>> >>> Ok, done >>> >>>>> + } >>>>> + /* Convert X TRUTH-ANDORIF Y to X TRUTH-ANDOR Y, if X and Y >>>>> + are simple operands and have no side-effects. */ >>>>> + if (simple_operand_p (arg0) >>>>> + && !TREE_SIDE_EFFECTS (arg0)) >>>> >>>> Again, the checks you do for arg0 do not match those for arg1. OTOH >>>> it doesn't matter whether arg0 is simple or not or has side-effects or >>>> not for this transformation, so why check it at all? >>> >>> It is required. For left-hand operand, if it isn't a logical >>> and/or/xor, we need to check for side-effects (and for trapping). I >>> see that calling of simple_operand_p is wrong here, as it rejects too >>> much. Nevertheless the check for side-effects is necessary for having >>> valid sequence-points. Without that checking a simple test >> >> So said, it is even required to use for right-hand and left-hand side >> of arguments, if one of them have side-effects or isn't simple. Means >> the check in my patch should use for >> >>> + else if (TREE_CODE (arg0) != TRUTH_AND_EXPR >>> + && TREE_CODE (arg0) != TRUTH_OR_EXPR >>> + && TREE_CODE (arg0) != TRUTH_ANDIF_EXPR >>> + && TREE_CODE (arg0) != TRUTH_ORIF_EXPR >>> + && TREE_CODE (arg0) != TRUTH_XOR_EXPR >>> + /* Needed for sequence points and trappings, or side-effects. */ >>> + && !TREE_SIDE_EFFECTS (arg0) >>> + && !tree_could_trap_p (arg0)) >>> + return fold_build2_loc (loc, ncode, type, arg0, arg1); >> >> instead if (!TREE_SIDE_EFFECTS (arg0) && simple_operand_p (arg0)) .... >> instead. >> >> The cause for this are the consitancies of sequences in tree. I >> noticed that by tests in gcc.dg/tree-ssa about builitin_expect. >> >> for example we have >> >> extern int foo (void); /* foo modifies gbl1 */ >> int gbl1 = 0; >> >> int foo (int ns1) >> { >> if (ns1 && foo () && gbl1) >> return 1; >> return 0; >> } >> >> so chain of trees has to look like this: >> (ANDIF (ns1 (ANDIF foo () gbl1)) >> >> but if we don't check here for side-effects for left-hand chaining >> operand, then we end up with >> (AND ns1 (ANDIF foo () gbl1)) > > No we don't, as the right-hand (ANDIF foo () glbl1) has side-effects. > >> As AND and has associative property, tree says that right-hand and >> left-hand are exchangable, which is obviously wrong. > > The poitn is that if the right-hand does not have side-effects it doesn't > matter if we execute it before the left-hand (independent on whether > that has side-effects or not). > > Richard. thats just true as long as we don't make use of associative law for AND expressions. Otherwise we would fail for much simpler cases like entern int doo (); int foo () { int c, r = 0; if ((c = foo ()) != 0 && c < 20) r = 1; return 0; } as for this left-hand operand has side-effects, but as it is the first one, we would chain it as AND. So we get wrong sequence. Kai
Sample had a typo. Correct sample has of course to return r.
int foo ()
{
int c, r = 0;
if ((c = foo ()) != 0 && c < 20)
r = 1;
return r;
}
On Mon, Oct 10, 2011 at 12:47 PM, Kai Tietz <ktietz70@googlemail.com> wrote: > 2011/10/10 Richard Guenther <richard.guenther@gmail.com>: >> On Mon, Oct 10, 2011 at 12:35 PM, Kai Tietz <ktietz70@googlemail.com> wrote: >>> 2011/10/7 Kai Tietz <ktietz70@googlemail.com>: >>>> Hello, >>>> >>>> this is the updated version with the suggestion >>>> >>>> 2011/10/7 Richard Guenther <richard.guenther@gmail.com>: >>>>> On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz <ktietz@redhat.com> wrote: >>>>>> + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison >>>>>> + && TREE_CODE (arg1) != TRUTH_NOT_EXPR >>>>>> + && simple_operand_p (arg1)) >>>>> >>>>> As I said previously simple_operand_p already rejects covers >>>>> comparisons and TRUTH_NOT_EXPR. Also arg1 had better >>>>> TREE_SIDE_EFFECTS set if the comparison might trap, as >>>>> it might just be hidden in something more complicated - so >>>>> the simple check isn't enough anyway (and if simple_operand_p >>>>> would cover it, the check would be better placed there). >>>> >>>> I reworked simple_operand_p so that it does this special-casing and additionally >>>> also checks for trapping. >>>> >>>>>> + if (TREE_CODE (arg0) == code >>>>>> + && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1)) >>>>>> + && simple_operand_p (TREE_OPERAND (arg0, 1))) >>>>>> + { >>>>>> + tem = build2_loc (loc, >>>>>> + (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR >>>>>> + : TRUTH_OR_EXPR), >>>>>> + type, TREE_OPERAND (arg0, 1), arg1); >>>>>> + return build2_loc (loc, code, type, TREE_OPERAND (arg0, 0), >>>>>> + tem); >>>>> >>>>> All trees should be folded, don't use plain build without a good reason. >>>> >>>> Ok, done >>>> >>>>>> + } >>>>>> + /* Convert X TRUTH-ANDORIF Y to X TRUTH-ANDOR Y, if X and Y >>>>>> + are simple operands and have no side-effects. */ >>>>>> + if (simple_operand_p (arg0) >>>>>> + && !TREE_SIDE_EFFECTS (arg0)) >>>>> >>>>> Again, the checks you do for arg0 do not match those for arg1. OTOH >>>>> it doesn't matter whether arg0 is simple or not or has side-effects or >>>>> not for this transformation, so why check it at all? >>>> >>>> It is required. For left-hand operand, if it isn't a logical >>>> and/or/xor, we need to check for side-effects (and for trapping). I >>>> see that calling of simple_operand_p is wrong here, as it rejects too >>>> much. Nevertheless the check for side-effects is necessary for having >>>> valid sequence-points. Without that checking a simple test >>> >>> So said, it is even required to use for right-hand and left-hand side >>> of arguments, if one of them have side-effects or isn't simple. Means >>> the check in my patch should use for >>> >>>> + else if (TREE_CODE (arg0) != TRUTH_AND_EXPR >>>> + && TREE_CODE (arg0) != TRUTH_OR_EXPR >>>> + && TREE_CODE (arg0) != TRUTH_ANDIF_EXPR >>>> + && TREE_CODE (arg0) != TRUTH_ORIF_EXPR >>>> + && TREE_CODE (arg0) != TRUTH_XOR_EXPR >>>> + /* Needed for sequence points and trappings, or side-effects. */ >>>> + && !TREE_SIDE_EFFECTS (arg0) >>>> + && !tree_could_trap_p (arg0)) >>>> + return fold_build2_loc (loc, ncode, type, arg0, arg1); >>> >>> instead if (!TREE_SIDE_EFFECTS (arg0) && simple_operand_p (arg0)) .... >>> instead. >>> >>> The cause for this are the consitancies of sequences in tree. I >>> noticed that by tests in gcc.dg/tree-ssa about builitin_expect. >>> >>> for example we have >>> >>> extern int foo (void); /* foo modifies gbl1 */ >>> int gbl1 = 0; >>> >>> int foo (int ns1) >>> { >>> if (ns1 && foo () && gbl1) >>> return 1; >>> return 0; >>> } >>> >>> so chain of trees has to look like this: >>> (ANDIF (ns1 (ANDIF foo () gbl1)) >>> >>> but if we don't check here for side-effects for left-hand chaining >>> operand, then we end up with >>> (AND ns1 (ANDIF foo () gbl1)) >> >> No we don't, as the right-hand (ANDIF foo () glbl1) has side-effects. >> >>> As AND and has associative property, tree says that right-hand and >>> left-hand are exchangable, which is obviously wrong. >> >> The poitn is that if the right-hand does not have side-effects it doesn't >> matter if we execute it before the left-hand (independent on whether >> that has side-effects or not). >> >> Richard. > > thats just true as long as we don't make use of associative law for > AND expressions. > Otherwise we would fail for much simpler cases like > entern int doo (); > int foo () > { > int c, r = 0; > if ((c = foo ()) != 0 && c < 20) > r = 1; > return 0; > } > > as for this left-hand operand has side-effects, but as it is the first > one, we would chain it as AND. So we get wrong sequence. Well, then the predicates checking for simplicity and side-effects should better match. Richard. > Kai >
On Fri, Oct 7, 2011 at 11:36 PM, Kai Tietz <ktietz70@googlemail.com> wrote: > Hello, > > this is the updated version with the suggestion > > 2011/10/7 Richard Guenther <richard.guenther@gmail.com>: >> On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz <ktietz@redhat.com> wrote: >>> + && ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison >>> + && TREE_CODE (arg1) != TRUTH_NOT_EXPR >>> + && simple_operand_p (arg1)) >> >> As I said previously simple_operand_p already rejects covers >> comparisons and TRUTH_NOT_EXPR. Also arg1 had better >> TREE_SIDE_EFFECTS set if the comparison might trap, as >> it might just be hidden in something more complicated - so >> the simple check isn't enough anyway (and if simple_operand_p >> would cover it, the check would be better placed there). > > I reworked simple_operand_p so that it does this special-casing and additionally > also checks for trapping. > >>> + if (TREE_CODE (arg0) == code >>> + && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1)) >>> + && simple_operand_p (TREE_OPERAND (arg0, 1))) >>> + { >>> + tem = build2_loc (loc, >>> + (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR >>> + : TRUTH_OR_EXPR), >>> + type, TREE_OPERAND (arg0, 1), arg1); >>> + return build2_loc (loc, code, type, TREE_OPERAND (arg0, 0), >>> + tem); >> >> All trees should be folded, don't use plain build without a good reason. > > Ok, done > >>> + } >>> + /* Convert X TRUTH-ANDORIF Y to X TRUTH-ANDOR Y, if X and Y >>> + are simple operands and have no side-effects. */ >>> + if (simple_operand_p (arg0) >>> + && !TREE_SIDE_EFFECTS (arg0)) >> >> Again, the checks you do for arg0 do not match those for arg1. OTOH >> it doesn't matter whether arg0 is simple or not or has side-effects or >> not for this transformation, so why check it at all? > > It is required. For left-hand operand, if it isn't a logical > and/or/xor, we need to check for side-effects (and for trapping). I > see that calling of simple_operand_p is wrong here, as it rejects too > much. Nevertheless the check for side-effects is necessary for having > valid sequence-points. Without that checking a simple test > > int getter (void); > > int foo (void) > { > int c, r = 0; > while ((c = getter ()) != '"' && c >= 0) > r +=c; > return r; > } > > would give a warning about sequence-points. As left-hand operand has > side-effects, but right-hand not. If we would combine it as AND, the > operands are exchange-able. So right-hand operand needs to be another > ANDIF expression instead. > Same apply on trapping. > >> In fold_truthop we still have the same (albeit more restricted transform), >> but guarded with >> >> if (BRANCH_COST (optimize_function_for_speed_p (cfun), >> false) >= 2 >> >> too. Why not here? Please delete redundant code in fold_truthop. > Well, in general this is the default definition of > LOGICAL_OP_NON_SHORT_CIRCUIT, so I missed that. As for some targets > the macro LOGICAL_OP_NON_SHORT_CIRCUIT might be defined differently, > it might make sense to check for BRANCH_COST again. > >> It's also odd that this is only called from fold_truth_andor but has >> a more generic name, so maybe rename it to fold_truth_andor_1 on the way. > > I renamed it. > >> Richard. > > ChangeLog > > 2011-10-07 Kai Tietz <ktietz@redhat.com> > > * fold-const.c (simple_operand_p): Make argument non-const > and add floating-point trapping check, and special cases for > comparisons, and logical-not's. > (fold_truthop): Rename to > (fold_truth_andor_1): function name. > Additionally remove here TRUTH-AND|OR_EXPR generation. > (fold_truth_andor): Handle branching at one place. > > 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 > @@ -111,14 +111,13 @@ static tree decode_field_reference (loca > tree *, tree *); > 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 int simple_operand_p (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 +3499,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,17 +3667,43 @@ 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 > -simple_operand_p (const_tree exp) > +simple_operand_p (tree exp) > { > + enum tree_code code; > /* Strip any conversions that don't change the machine mode. */ > STRIP_NOPS (exp); > > + code = TREE_CODE (exp); > + > + /* Handle some trivials $$$$ */ > + if (TREE_CODE_CLASS (code) == tcc_comparison) > + return (tree_could_trap_p (exp) > + && simple_operand_p (TREE_OPERAND (exp, 0)) > + && simple_operand_p (TREE_OPERAND (exp, 1))); Clearly wrong. And what's $$$$ supposed to be? > + > + 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 (TREE_OPERAND (exp, 0)); > + case BIT_NOT_EXPR: > + if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE) > + return false; > + return simple_operand_p (TREE_OPERAND (exp, 0)); > + default: > + break; > + } > + You add a lot of cases here without a good reason. Why in this patch? Simply removing the tcc_comparison checks would have been enough ... > return (CONSTANT_CLASS_P (exp) > - || TREE_CODE (exp) == SSA_NAME > || (DECL_P (exp) > && ! TREE_ADDRESSABLE (exp) > && ! TREE_THIS_VOLATILE (exp) > @@ -4888,7 +4913,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 fold_truth_andor > 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 +5050,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 +5079,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 +5142,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 +5171,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 +8395,52 @@ 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 (arg1)) > + { > + enum tree_code ncode = (code == TRUTH_ANDIF_EXPR ? TRUTH_AND_EXPR > + : TRUTH_OR_EXPR); > + > + /* We don't want to pack more then two non-IF branches > + together. Therefore we need to check, if rhs isn't > + already an TRUTH_(XOR|OR|AND)[IF]_EXPR. */ which means, just check if (simple_operand_p (arg0)) ... > + if (TREE_CODE (arg0) == code > + && TREE_CODE (TREE_OPERAND (arg0, 1)) != TRUTH_AND_EXPR > + && TREE_CODE (TREE_OPERAND (arg0, 1)) != TRUTH_OR_EXPR > + && TREE_CODE (TREE_OPERAND (arg0, 1)) != TRUTH_XOR_EXPR > + && TREE_CODE (TREE_OPERAND (arg0, 1)) != TRUTH_ANDIF_EXPR > + && TREE_CODE (TREE_OPERAND (arg0, 1)) != TRUTH_ORIF_EXPR > + /* Needed for sequence points and trappings, or side-effects. */ > + && !TREE_SIDE_EFFECTS (TREE_OPERAND (arg0, 1)) > + && !tree_could_trap_p (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); Don't do this association here. Why should it not be applied to (a TRUTH_ANDIF_EXPR b) TRUTH_AND_EXPR c? Thus, if you want to associate the above if b and c do not have side-effects then do so generally, not only when you are converting a TRUTH_ANDIF_EXPR to TRUTH_AND_EXPR. Thus, please remove this association code. > + } > + else if (TREE_CODE (arg0) != TRUTH_AND_EXPR > + && TREE_CODE (arg0) != TRUTH_OR_EXPR > + && TREE_CODE (arg0) != TRUTH_ANDIF_EXPR > + && TREE_CODE (arg0) != TRUTH_ORIF_EXPR > + && TREE_CODE (arg0) != TRUTH_XOR_EXPR > + /* Needed for sequence points and trappings, or side-effects. */ > + && !TREE_SIDE_EFFECTS (arg0) > + && !tree_could_trap_p (arg0)) See above. You made the patch more complex when I asked for a simpler one. Richard. > + return fold_build2_loc (loc, ncode, type, arg0, arg1); > + } > + > return NULL_TREE; > } >
Hi, On Mon, 10 Oct 2011, Kai Tietz wrote: > extern int foo (void); /* foo modifies gbl1 */ > int gbl1 = 0; > > int foo (int ns1) > { > if (ns1 && foo () && gbl1) > return 1; > return 0; > } > > so chain of trees has to look like this: > (ANDIF (ns1 (ANDIF foo () gbl1)) Okay, indeed. I was wrong when I claimed that only the RHS needs to be side-effect-free for ANDIF->AND to be valid. It's true when the RHS can't depend on the LHS, but I only thought about the fact that the side-effect must occur, not that it possibly influences RHS. Ciao, Michael.
Index: gcc/gcc/fold-const.c =================================================================== --- gcc.orig/gcc/fold-const.c +++ gcc/gcc/fold-const.c @@ -111,14 +111,13 @@ static tree decode_field_reference (loca tree *, tree *); 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 int simple_operand_p (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);