On 5/6/19 3:36 PM, Richard Biener wrote: > 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 >>> <seg...@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 >>>> <seg...@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.
Yes, mainly libsanitizer run-time libraries build is a pain. > >> 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. I can provide access to multiple high-core machines we have at SUSE ;) Martin > > Richard. >
