Re: [RFH] split {generic,gimple}-match.c files

[Richard Biener <rguenther@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

On Mon, 6 May 2019, Martin Liška wrote:

> On 5/2/19 9:04 PM, Richard Biener wrote:
> > On May 2, 2019 8:14:46 PM GMT+02:00, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >> On Thu, May 02, 2019 at 07:41:18PM +0200, Richard Biener wrote:
> >>> On May 2, 2019 7:00:16 PM GMT+02:00, Segher Boessenkool
> >> <segher@kernel.crashing.org> wrote:
> >>>> On Thu, May 02, 2019 at 03:18:00PM +0200, Richard Biener wrote:
> >>>>> Somewhen earlier this year I've done the experiment with using
> >>>>> a compile with -flto -fno-fat-lto-objects and a link
> >>>>> via -flto -r -flinker-output=rel into the object file.  This cut
> >>>>> compile-time more than in half with less maintainance overhead.
> >>>>>
> >>>>> Adding other files to this handling looks trivial as well, as well
> >>>>> as conditionalizing it (I'd probably not want this for devel
> >> builds).
> >>>>
> >>>> But we want devel builds to be a lot faster than they are now :-/
> >>>
> >>> My devel build is -O0 non-bootstrapped and building the files after
> >> dependency changes is fast enough. It's the bootstraps that matter, no?
> >>
> >>
> >> Yes, I bootstrap most of the time.  For development.  It catches a
> >> *lot*
> >> of problems progressive builds do not.  (Those are plenty fast already
> >> of
> >> course, -O0 or not).
> > 
> > So we'd catch it there but disable by default for stage 1 since we probably do not want to rely on the host compiler. 
> > 
> > Richard. 
> > 
> >>
> >> Segher
> > 
> 
> I'm interested in 2 scenarios:
> 
> 1) fast non-bootstrap development build with -O2; typically I want to run a fraction of test-suite or
> I want to install the compiler and run-time binaries; building the compiler with -O0 will result in terribly
> slow build of run-time libraries

That's already overall "fast", mostly dominated by runtime library build.

> 2) faster bootstrap on a massively parallel machine (64+ cores)

I guess for this we can also try to do LTO bootstap and
LTO-link libbackend itself.  LTO bootstrap is only slow because
we build everything 12 times.

I'm most interested in faster bootstrap on low-core machines
(4 to 6 physical cores), since that's what I am doing most of the time.
This is dominated by testing time, not bootstrap time.

Richard.