[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [RFA] Limit stack usage growth caused by inliner
From:       Jan Hubicka <jh () suse ! cz>
Date:       2006-11-30 15:17:24
Message-ID: 20061130151724.GG16780 () kam ! mff ! cuni ! cz
[Download RAW message or body]

> On Thu, Nov 30, 2006 at 04:07:04PM +0100, Jan Hubicka wrote:
> > > FYI, this patch causes a bunch of regressions on the trunk, x86_64-linux:
> > > FAIL: libgomp.c++/nested-1.C  -O0  execution test
> > > FAIL: libgomp.c++/nested-1.C  -O1  execution test
> > > FAIL: libgomp.c++/pr27337.C  -O1  execution test
> > > FAIL: libgomp.fortran/character1.f90  -O0  execution test
> > > FAIL: libgomp.fortran/omp_parse4.f90  -O1  execution test
> > > FAIL: libgomp.fortran/reference1.f90  -O0  execution test
> > > FAIL: libgomp.fortran/reference2.f90  -O0  execution test
> > > 
> > > Reverting the {cgraph{,unit},ipa-inline,cfgexpand}.c changes cures all of
> > > these.
> > 
> > I am seeing those regressions comming and disappearing quite randomly in
> > our patch tester,  I wonder if you have any idea what might be causing
> > the problem?  (only effect of the patch should be disabling some
> > inlining or inlining something elsewhere instead, that should not change
> > any semantics so it looks like latent problem I always assumed to be in
> > our setup)
> 
> This is the first time I saw these failures.  There is no inlining involved
> here at all (at least not in nested-1.C) and most of the failures are at
> -O0.  027t.ompexp dumps (last at -O0) are identical with or without that patch, but
> already 104r.expand there are many differences, mainly different stack size
> and stack offsets.

I see, I will re-review the cfgexpand changes if I didn't missed
something obvious while merging the code (I originally just forked the
implementation and then decided it is better to share it more).

Honza
[prev in list] [next in list] [prev in thread] [next in thread]