Patchwork Revert PARAM_SCEV_MAX_EXPR_SIZE change

login
register
mail settings
Submitter Richard Guenther
Date Feb. 1, 2011, 12:59 p.m.
Message ID <alpine.LNX.2.00.1102011354540.17230@zhemvz.fhfr.qr>
Download mbox | patch
Permalink /patch/81303/
State New
Headers show

Comments

Richard Guenther - Feb. 1, 2011, 12:59 p.m.
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.
Sebastian Pop - Feb. 1, 2011, 5:06 p.m.
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
Richard Guenther - Feb. 1, 2011, 5:11 p.m.
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
>
Sebastian Pop - Feb. 1, 2011, 5:13 p.m.
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
Sebastian Pop - Feb. 1, 2011, 5:22 p.m.
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;
H.J. Lu - Feb. 1, 2011, 6:18 p.m.
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.
Richard Guenther - Feb. 1, 2011, 10:26 p.m.
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;
>

Patch

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",