Re: mainline "exploding"

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, 2003-10-15 at 03:40, Jan Hubicka wrote:
> > > On Tue, 14 Oct 2003, Jan Hubicka wrote:
> > > > 
> > > > > 2) go ahead and enable unit-at-a-time by default for C++ at all levels
> > >  
> > > On Tue, Oct 14, 2003 at 02:28:53PM +0200, Michael Matz wrote:
> > > > IMHO, if possible we should go this way.  Maybe combined with lower limits
> > > > at -O1.  In the long run I see no sense in having two inlining heuristics.
> > > 
> > > Certainly if we have two inlining algorithms we have to keep maintaining,
> > > tuning, and bug-fixing two inlining algorithms.  Making the poorer one go
> > > away seems advisable.  I might have been confused, but the main argument
> > > I heard against using unit-at-a-time all the time was memory, so if we
> > > actually need more memory to use the old algorithm in many cases, that kills
> > > that.
> > 
> > Memory footprint does not appear to be catastrophical.  Even with
> > inlining disabled, for many copilation units, such as  combine.c the
> > peak is actually lower with -funit-at-a-time than without.
> 
> I think that every one agrees that -funit-at-a-time is where we want to
> go.  That was my plan when I implementation function-at-a-time years
> ago; it's clearly the right thing from a design perspective, and it is
> what every other compiler does.  Therefore, if it uses more memory than
> other compilers it's because of problems with GCC, not problems with the
> idea of -funit-at-a-time.
> 
> I think we should make -funit-at-a-time the default at this point, if it
> is passing test suites.
> 
> In fact, I think we should make it *unconditional*.  There is no need
> for this to be an option; it should be the only mode.

I would love to see -funit-at-a-time by default too, just because it
would make my life easier (even when now when we have commonized most of
code on  -funit-at-a-time and -fno-unit-at-a-time path) and I also
beleve it is way to go :)

But do we really want to break our runtime, glibc, kernel and probably
some other programs making funny assumptions about relative placements
of datastructures, variables and toplevel asm statements not preserved
by -funit-at-a-time from release to release?  (I would not worry that
much in longer term - most of instances are relatively easy to fix and
many fixed already, hardest is probably the GCC runtime)

Perhaps I can work on something like conservative -funit-at-a-time mode
(huh, yet another mode) that does make no function reorder or global
optimization if this does sound like good idea.  What I would definitly
not want to over with is having non-unit-at-a-time cgraph aware at -O0
C, java, C++, funny-unit-at-a-time at -O1, real-unit-at-a-time at -O2
and non-unit-at-a-time cgraph unaware with gfortran...
(luckilly enought I do not worry much about non-function-at-a-time stuff)

so I would take this step (probably not taking more than few days, but
still adding maintenance cost) only if there is chance to have it at
-O0.

Honza
> 
> -- 
> Mark Mitchell <mark@codesourcery.com>
> CodeSourcery, LLC