[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires > 20GB in 4.2.* and higher

[rguenther at suse dot de]

------- Comment #22 from rguenther at suse dot de  2009-02-13 11:06 -------
Subject: Re:  Code that compiles fine in 1GB of memory
 with 4.1.2 requires > 20GB in 4.2.* and higher

On Thu, 12 Feb 2009, lucier at math dot purdue dot edu wrote:

> ------- Comment #19 from lucier at math dot purdue dot edu  2009-02-12 20:51 -------
> Subject: Re:  Code that compiles fine in 1GB of
>  memory with 4.1.2 requires > 20GB in 4.2.* and higher
> 
> On Thu, 2009-02-12 at 16:52 +0000, rguenth at gcc dot gnu dot org wrote:
> > ------- Comment #16 from rguenth at gcc dot gnu dot org  2009-02-12 16:52 -------
> > Actually for PR26854 it is just one loop that is detected, covering all of
> > the function (with approx. 56000 basic blocks and one basic-block that has
> > edges to all other basic blocks in the loop).
> 
> Richard:
> 
> I'm wondering if you could look at a smaller file that's generated in a
> somewhat different way.
> 
> At
> 
> http://www.math.purdue.edu/~lucier/bugzilla/8/
> 
> there's a file _num.i.gz that I think should have smaller (nested) loops
> than the entire file, for example, from the label
> 
> ___L189__23__23_bignum_2e__2a_:
> 
> at line 50031 to just before label
> 
> ___L190__23__23_bignum_2e__2a_:
> 
> at line 50105.
> 
> Moving loop invariants out of this loop might help if it detected as a
> loop, but I don't know how to check whether it is.
> 
> Perhaps you might check and report whether this small loop is treated as
> a loop or whether, again, the entire function is the only "loop"
> detected.

Yes, there are several small loops detected for this testcase (139 in
total, including one large with the computed goto).

Btw, thanks for the smaller testcase.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157