> -----Original Message----- > From: Jeffrey Law <[email protected]> > Sent: 04 August 2026 17:26 > To: [email protected]; [email protected] > Cc: Tamar Christina <[email protected]>; > [email protected] > Subject: Re: [PATCH 1/2] genopinit: Distribute generated code across multiple > files > > > > On 7/23/2026 7:20 AM, [email protected] wrote: > > From: Kyrylo Tkachov <[email protected]> > > > > insn-opinit.cc contains large generated initialization functions with > > thousands of target-feature expressions. The single file is among the > > slowest objects in every AArch64 bootstrap stage. > > > > Teach genopinit to accept repeatable -O output options, following genemit > and > > genrecog. Reuse the existing --with-insnemit-partitions count, while > > preserving the default init-opinit.c output and -cFILE interface when -O is > > not > > used. Collect and validate all output names before opening them, rejecting > > duplicates, resolvable aliases, header collisions, and incompatible -c and > > -O > > options. > > > > Keep shared lookup code and all helper declarations in the first output, > > then > > place helper definitions in the shortest output. One-file output retains > > the > > historical static helper names. Split output uses generator-private > > external > > names for cross-file references. > > > > With the default ten AArch64 partitions, the largest part compiles about 90% > > faster than the original single object. > > > > Bootstrapped and tested on aarch64-none-linux-gnu and x86_64-linux. > > Ok for trunk? > > Thanks, > > Kyrill > > > > gcc/ChangeLog: > > > > * Makefile.in (INSNOPINIT_SPLITS_SEQ, INSNOPINIT_SEQ_SRC) > > (INSNOPINIT_SEQ_TMP, INSNOPINIT_SEQ_O): New variables. > > (OBJS): Replace insn-opinit.o with $(INSNOPINIT_SEQ_O). > > (MOSTLYCLEANFILES): Add $(INSNOPINIT_SEQ_SRC), retaining the > legacy > > unnumbered source for cleanup. > > (s-opinit): Generate and move numbered insn-opinit-N.cc files. Stop if > > moving an output fails. > > * configure.ac (--with-insnemit-partitions): Mention genopinit > outputs. > > * configure: Regenerate. > > * genopinit.cc (source_file_option, output_file_names, output_files): > > New variables. > > (handle_arg): Record and validate repeatable -O output names. > > (main): Validate all output modes before opening files. Preserve static > > helper linkage for one output and distribute private split helpers. > > > > Signed-off-by: Kyrylo Tkachov <[email protected]> > It'll be interesting to see if this improves the RISC-V build times > too. Robin fixed the worst of the offenders a while back, but we've got > daily build data and if there's a meaningful improvement we should be > able to see it. > > The only concern is the INSNOPINIT_SPLITS_SEQ is slightly different than > the other _SEQ variables. The others use: > > MATCH_SPLITS_SEQ = $(wordlist 1,$(NUM_MATCH_SPLITS),$(one_to_9999)) > INSNEMIT_SPLITS_SEQ = $(wordlist > 1,$(NUM_INSNEMIT_SPLITS),$(one_to_9999)) > INSNRECOG_SPLITS_SEQ = $(wordlist > 1,$(NUM_INSNEMIT_SPLITS),$(one_to_9999)) > > Is there a reason you didn't use that form?
So I've been ignoring this since it's mostly Richard's thing and we seem to disagree on design a lot. But in my opinion we don't want to keep adding split code to every gen* file individually but concentrate that code in gensupport so ever gen* can use it. At the same time I also think we should have one configure option. Back in the day my unsubmitted patch series used `:` to denote the different split values. So`5:6:8` meant Split XX in 5 pieces, XY in 6 and XZ in 8. This because the size of the generated files aren't the same for all gen* code. Lastly I also don't think splitting on an iterative way is going to give you the best compile time increase. Because that tends to bias the output. In genmatch I use ftell to tell how big the files is so far an pick the smallest file. This allows me to balance out the compile time over all files. I believe Robin eventually respun his gen<something> match to do this a swell as that allows you to amortize the compile time over cores. So I really would like to see the infrastructure for splitting unified... but this is a step into Improvement. FWIW, I abandoned my original changes here wrt to splitting to do it in a fundamentally different way. But I'm doing that in my own free time :) anyway feel free to ignore this, but it would be nice if we could refactor the splitting code. Thanks, Tamar > > jeff
