On Wed, May 12, 2021 at 10:19:17AM +0200, Richard Biener wrote: > On Tue, May 11, 2021 at 5:01 PM Segher Boessenkool > <seg...@kernel.crashing.org> wrote: > > > > On Tue, May 04, 2021 at 10:40:38AM +0200, Richard Biener via Gcc wrote: > > > On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc <gcc@gcc.gnu.org> > > > wrote: > > > > I noticed my (highly, -j24) parallel build of GCC is serialized on > > > > compiling gimple-match.c. Has anyone looked into splitting this > > > > generated file into multiple files? > > > > > > There were threads about this in the past, yes. There's the > > > possibility to use LTO for this as well (also mentioned in those > > > threads). Note it's not easy to split in a meaningful way in > > > genmatch.c > > > > But it will have to be handled at least somewhat soon: on not huge > > parallelism (-j120 for example) building *-match.c takes longer than > > building everything else in gcc/ together (wallclock time), and it is a > > huge part of regstrap time (bigger than running all of the testsuite!) > > I would classify -j120 as "huge parallelism" ;) Testing time still > dominates my builds (with -j24) where bootstrap takes ~20 mins > but testing another 40.
The issue is that the usual regstrap has become something like 2x slower over five or so years. Hardware doesn't keep up (per thread), so the only way to keep acceptable turnaround times is to up the thread count. And then the few tasks that take way more time than everything else will dominate. > Is it building stage2 gimple-match.c that you are worried about? > (it's built using the -O0 compiled stage1 compiler - but we at > least should end up using -fno-checking for this build) The *-match builds in other stages are noticeably slow as well. But yes, stage2 is by far slowest. > Maybe you can do some experiments - like add > -fno-inline-functions-called-once and change > genmatch.c:3766 to split out single uses as well > (should decrease function sizes). > > There's the option to make all functions external in > gimple-match.c so splitting the file at arbitrary points > will be possible (directly from genmatch), we'll need > some internal header with all declarations then > as well or alternatively some clever logic in > genmatch to only externalize functions needed from > mutliple split files. > > That said - ideas to reduce the size of the generated > code are welcome as well. I don't currently have good plans for this. I'm just remarking that it increasingly is the biggest bootstrap time problem. It always has been, but it has become significantly worse the past few releases. [ snip a lot I cannot reply to right now ] > -fno-checking also makes a dramatic difference for me. Checking quite often finds serious problems, so that is not a real option, neither during development nor while just testing configurations. I even like to enable rtl,tree checking even though that costs a factor of three or so build time. Disabling all checking most of the time is counter-productive imo. Segher
