RE: [PATCH 1/2] genopinit: Distribute generated code across multiple files

> -----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 mult=
iple
> files
>=20
>=20
>=20
> 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 genem=
it
> 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, rejec=
ting
> > 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 retai=
ns the
> > historical static helper names.  Split output uses generator-private ex=
ternal
> > names for cross-file references.
> >
> > With the default ten AArch64 partitions, the largest part compiles abou=
t 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 i=
f
> > 	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 stat=
ic
> > 	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.=A0 Robin fixed the worst of the offenders a while back, but we've go=
t
> daily build data and if there's a meaningful improvement we should be
> able to see it.
>=20
> The only concern is the INSNOPINIT_SPLITS_SEQ is slightly different than
> the other _SEQ variables.=A0 =A0 The others use:
>=20
> MATCH_SPLITS_SEQ =3D $(wordlist 1,$(NUM_MATCH_SPLITS),$(one_to_9999))
> INSNEMIT_SPLITS_SEQ =3D $(wordlist
> 1,$(NUM_INSNEMIT_SPLITS),$(one_to_9999))
> INSNRECOG_SPLITS_SEQ =3D $(wordlist
> 1,$(NUM_INSNEMIT_SPLITS),$(one_to_9999))
>=20
> 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* fil=
e 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 ge=
nerated files aren't
the same for all gen* code.

Lastly I also don't think splitting on an iterative way is going to give yo=
u 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 sma=
llest file. This allows
me to balance out the compile time over all files. I believe Robin eventual=
ly 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... b=
ut this is a step into
Improvement.  FWIW, I abandoned my original changes here wrt to splitting t=
o 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

>=20
> jeff