Revert PARAM_SCEV_MAX_EXPR_SIZE change

Submitted by Richard Guenther on Feb. 1, 2011, 12:59 p.m.

Details

Message ID alpine.LNX.2.00.1102011354540.17230@zhemvz.fhfr.qr
State New
Headers show

Commit Message

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.

Comments

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 hide | download patch | download mbox

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