This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix bootstrap compile time blowout on x86_64.

> On Sat, 2006-12-09 at 12:20 +0100, Richard Guenther wrote:
> > On 12/9/06, Maxim Kuvyrkov <> wrote:
> > > Hi!
> > >
> > > Thanks to Jan Hubicka an issue with compile time blowout came up.  Over
> > > 80% of insn-attrtab.c compile time is spent in haifa-sched.c: check_cfg
> > > () function which does sanity check of the whole CFG.  There are three
> > > callers of check_cfg () at the moment: sched_init (), schedule_block ()
> > > and sched_finish ().  While calls from sched_{init, finish} () are done
> > > once per function the call from schedule_block () is invoked for every
> > > single basic block.  Leaving only two of the three calls - sched_{init,
> > > finish} () - will pretty much solve the problem.  Please find the patch
> > > attached.
> > >
> > > OK for trunk and gcc-4_2-branch?
> So this is only an issue with checking enabled, then why is this really
> an issue?  Yes people might complain about the compile time speed for
> bootstrap but this only happens while compiling stage2 if we do
> --enable-checking=release.

The slower our bootstraps are, the longer it takes us to develop
something.  I think it is perfectly sane to trottle down the most
expensive checks especially when they are showing during bootstrap.  You
don't want to have --enable-checking=gcac by default for development

Note that the check_cfg is still being used, just constant times per
function, instead of N times per function.  So we will get notified
about the possible bug, just bit later than previously. 

Checking stuff is meant to simplify life for us and let us develop more
easilly after all ;)

> Thanks,
> Andrew Pinski

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]