| Message ID | alpine.LNX.2.00.1102011354540.17230@zhemvz.fhfr.qr |
|---|---|
| State | New |
| Headers | show |
On Tue, Feb 1, 2011 at 06:59, Richard Guenther <rguenther@suse.de> wrote: > > This reverts us back to the 4.5 setting which fixes PR47555. The > parameter limits us to expression sizes on the "branchiness" > of expressions, to O(2^param), bumping that from 20 to 100 looks ... > unreasonable. The limit implementation might lack sense as it > doesn't really limit expression size. Anyway, this makes the > memory requiremens for building PR47555 drop from >3GB to 800MB > again. Ok. Is your machine testing graphite as well? There is a way to fix the memory hungriness of scev: that requires a normalization as we build new chains of recurrences. Sebastian
On Tue, Feb 1, 2011 at 6:06 PM, Sebastian Pop <sebpop@gmail.com> wrote: > On Tue, Feb 1, 2011 at 06:59, Richard Guenther <rguenther@suse.de> wrote: >> >> This reverts us back to the 4.5 setting which fixes PR47555. The >> parameter limits us to expression sizes on the "branchiness" >> of expressions, to O(2^param), bumping that from 20 to 100 looks ... >> unreasonable. The limit implementation might lack sense as it >> doesn't really limit expression size. Anyway, this makes the >> memory requiremens for building PR47555 drop from >3GB to 800MB >> again. > > Ok. Is your machine testing graphite as well? It did so in the past, I'd have to check with the recent configure changes. > There is a way to fix the memory hungriness of scev: that requires a > normalization as we build new chains of recurrences. Nothing for stage4. Richard. > Sebastian >
On Tue, Feb 1, 2011 at 11:11, Richard Guenther <richard.guenther@gmail.com> wrote: > On Tue, Feb 1, 2011 at 6:06 PM, Sebastian Pop <sebpop@gmail.com> wrote: >> On Tue, Feb 1, 2011 at 06:59, Richard Guenther <rguenther@suse.de> wrote: >>> >>> This reverts us back to the 4.5 setting which fixes PR47555. The >>> parameter limits us to expression sizes on the "branchiness" >>> of expressions, to O(2^param), bumping that from 20 to 100 looks ... >>> unreasonable. The limit implementation might lack sense as it >>> doesn't really limit expression size. Anyway, this makes the >>> memory requiremens for building PR47555 drop from >3GB to 800MB >>> again. >> >> Ok. Is your machine testing graphite as well? > > It did so in the past, I'd have to check with the recent configure changes. > It may have introduced http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47576 >> There is a way to fix the memory hungriness of scev: that requires a >> normalization as we build new chains of recurrences. > > Nothing for stage4. I agree. Sebastian
On Tue, Feb 1, 2011 at 11:13, Sebastian Pop <sebpop@gmail.com> wrote: > On Tue, Feb 1, 2011 at 11:11, Richard Guenther > <richard.guenther@gmail.com> wrote: >> On Tue, Feb 1, 2011 at 6:06 PM, Sebastian Pop <sebpop@gmail.com> wrote: >>> On Tue, Feb 1, 2011 at 06:59, Richard Guenther <rguenther@suse.de> wrote: >>>> >>>> This reverts us back to the 4.5 setting which fixes PR47555. The >>>> parameter limits us to expression sizes on the "branchiness" >>>> of expressions, to O(2^param), bumping that from 20 to 100 looks ... >>>> unreasonable. The limit implementation might lack sense as it >>>> doesn't really limit expression size. Anyway, this makes the >>>> memory requiremens for building PR47555 drop from >3GB to 800MB >>>> again. >>> >>> Ok. Is your machine testing graphite as well? >> >> It did so in the past, I'd have to check with the recent configure changes. >> > > It may have introduced http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47576 > >>> There is a way to fix the memory hungriness of scev: that requires a >>> normalization as we build new chains of recurrences. >> >> Nothing for stage4. > > I agree. We are wrongly using PARAM_SCEV_MAX_EXPR_SIZE to limit the scev analysis in two different places: the second has nothing to do with the expression size and that should be much lower like 10 or so: /* Give up if the path is longer than the MAX that we allow. */ if (limit > PARAM_VALUE (PARAM_SCEV_MAX_EXPR_SIZE)) return t_dont_know; This I think is fine with 100: /* Give up if the expression is larger than the MAX that we allow. */ if (size_expr++ > PARAM_VALUE (PARAM_SCEV_MAX_EXPR_SIZE)) return chrec_dont_know;
On Tue, Feb 1, 2011 at 4:59 AM, Richard Guenther <rguenther@suse.de> wrote: > > This reverts us back to the 4.5 setting which fixes PR47555. The > parameter limits us to expression sizes on the "branchiness" > of expressions, to O(2^param), bumping that from 20 to 100 looks ... > unreasonable. The limit implementation might lack sense as it > doesn't really limit expression size. Anyway, this makes the > memory requiremens for building PR47555 drop from >3GB to 800MB > again. > > Bootstrap and testing on x86_64-unknown-linux-gnu in progress. > > Richard. > > 2011-02-01 Richard Guenther <rguenther@suse.de> > > PR tree-optimization/47555 > Revert > 2010-07-15 Sebastian Pop <sebastian.pop@amd.com> > > * params.def (PARAM_SCEV_MAX_EXPR_SIZE): Bump the value to 100. > This triggered: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47576 H.J.
On Tue, Feb 1, 2011 at 6:22 PM, Sebastian Pop <sebpop@gmail.com> wrote: > On Tue, Feb 1, 2011 at 11:13, Sebastian Pop <sebpop@gmail.com> wrote: >> On Tue, Feb 1, 2011 at 11:11, Richard Guenther >> <richard.guenther@gmail.com> wrote: >>> On Tue, Feb 1, 2011 at 6:06 PM, Sebastian Pop <sebpop@gmail.com> wrote: >>>> On Tue, Feb 1, 2011 at 06:59, Richard Guenther <rguenther@suse.de> wrote: >>>>> >>>>> This reverts us back to the 4.5 setting which fixes PR47555. The >>>>> parameter limits us to expression sizes on the "branchiness" >>>>> of expressions, to O(2^param), bumping that from 20 to 100 looks ... >>>>> unreasonable. The limit implementation might lack sense as it >>>>> doesn't really limit expression size. Anyway, this makes the >>>>> memory requiremens for building PR47555 drop from >3GB to 800MB >>>>> again. >>>> >>>> Ok. Is your machine testing graphite as well? >>> >>> It did so in the past, I'd have to check with the recent configure changes. >>> >> >> It may have introduced http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47576 >> >>>> There is a way to fix the memory hungriness of scev: that requires a >>>> normalization as we build new chains of recurrences. >>> >>> Nothing for stage4. >> >> I agree. > > We are wrongly using PARAM_SCEV_MAX_EXPR_SIZE > to limit the scev analysis in two different places: the second has nothing > to do with the expression size and that should be much lower like 10 or so: > > /* Give up if the path is longer than the MAX that we allow. */ > if (limit > PARAM_VALUE (PARAM_SCEV_MAX_EXPR_SIZE)) > return t_dont_know; As I noted this isn't really "expression size", it's more like "expression complexity". I'll split it into a separate param. Richard. > This I think is fine with 100: > > /* Give up if the expression is larger than the MAX that we allow. */ > if (size_expr++ > PARAM_VALUE (PARAM_SCEV_MAX_EXPR_SIZE)) > return chrec_dont_know; >
Index: gcc/params.def =================================================================== --- gcc/params.def (revision 169434) +++ gcc/params.def (working copy) @@ -481,7 +481,7 @@ DEFPARAM(PARAM_IV_ALWAYS_PRUNE_CAND_SET_ DEFPARAM(PARAM_SCEV_MAX_EXPR_SIZE, "scev-max-expr-size", "Bound on size of expressions used in the scalar evolutions analyzer", - 100, 0, 0) + 20, 0, 0) DEFPARAM(PARAM_OMEGA_MAX_VARS, "omega-max-vars",