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