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

> On 5 Aug 2026, at 16:37, Kyrylo Tkachov <[email protected]> wrote:
> 
> 
> 
>> On 5 Aug 2026, at 10:11, Tamar Christina <[email protected]> wrote:
>> 
>>> -----Original Message-----
>>> From: Robin Dapp <[email protected]>
>>> Sent: 04 August 2026 20:21
>>> To: Tamar Christina <[email protected]>; Jeffrey Law
>>> <[email protected]>; [email protected]; gcc-
>>> [email protected]
>>> Cc: [email protected]; Robin Dapp <[email protected]>
>>> Subject: Re: [PATCH 1/2] genopinit: Distribute generated code across multiple
>>> files
>>> 
>>>> 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.
>>> 
>>> The individual splits are there because I started out with one
>>> (genemit), then later realized genrecog is large as well.  It was
>>> certainly not the initial intention to split everything individually.
>>> But I agree that by now we have reached a tipping point.
>>> 
>>> BTW I also touched opinit before, splitting one function into several,
>>> because it would trigger pathological compiler behavior.
>>> So we already perform some kind of splitting.  Are we sure we're not
>>> actually seeing pathological behavior again that could be helped by
>>> something else than file-level splitting?
>> 
>> geninit is also one that I think can benefit from a different way of generating
>> the values.
>> 
>> If you look at the large arrays it generates for like init_all_optabs
>> 
>> These are huge, and also result in at runtime just a series of branches and calls.
>> 
>> i.e.
>> 
>> static void
>> init_optabs_01 (struct target_optabs *optabs)
>> {
>> bool *ena = optabs->pat_enable;
>> ena[1000] = HAVE_udot_prodv2siv8qi;
>> ena[1001] = HAVE_udot_prodv4siv16qi;
>> ena[1002] = HAVE_udot_prodvnx8hivnx16qi;
>> ena[1003] = HAVE_udot_prodvnx4sivnx16qi;
>> ena[1004] = HAVE_udot_prodvnx4sivnx8hi;
>> ena[1005] = HAVE_udot_prodvnx2divnx8hi;
>> ena[1006] = HAVE_usdot_prodv2siv8qi;
>> ena[1007] = HAVE_usdot_prodv4siv16qi;
>> ena[1008] = HAVE_usdot_prodvnx4sivnx16qi;
>> ena[1009] = HAVE_while_ultsivnx16bi;
>> ena[1010] = HAVE_while_ultdivnx16bi;
>> ena[1011] = HAVE_while_ultsivnx8bi;
>> ena[1012] = HAVE_while_ultdivnx8bi;
>> ena[1013] = HAVE_while_ultsivnx4bi;
>> ena[1014] = HAVE_while_ultdivnx4bi;
>> ena[1015] = HAVE_while_ultsivnx2bi;
>> ena[1016] = HAVE_while_ultdivnx2bi;
>> ena[1017] = HAVE_addsi3;
>> ena[1018] = HAVE_adddi3;
>> ena[1019] = HAVE_addti3;
>> ena[1020] = HAVE_addhf3;
>> ena[1021] = HAVE_addsf3;
>> ena[1022] = HAVE_adddf3;
>> ena[1023] = HAVE_addv8qi3;
>> ena[1024] = HAVE_addv4hi3;
>> ena[1025] = HAVE_addv2si3;
>> ena[1026] = HAVE_addv16qi3;
>> ena[1027] = HAVE_addv8hi3;
>> ena[1028] = HAVE_addv4si3;
>> ena[1029] = HAVE_addv2di3;
>> ena[1030] = HAVE_addvnx16qi3;
>> ena[1031] = HAVE_addvnx8hi3;
>> ena[1032] = HAVE_addvnx4si3;
>> ena[1033] = HAVE_addvnx2di3;
>> ena[1034] = HAVE_addvnx2qi3;
>> ena[1035] = HAVE_addvnx4qi3;
>> ena[1036] = HAVE_addvnx2hi3;
>> ena[1037] = HAVE_addvnx8qi3;
>> ena[1038] = HAVE_addvnx4hi3;
>> ena[1039] = HAVE_addvnx2si3;
>> ena[1040] = HAVE_addv4hf3;
>> ena[1041] = HAVE_addv2sf3;
>> ena[1042] = HAVE_addv8hf3;
>> ena[1043] = HAVE_addv4sf3;
>> ena[1044] = HAVE_addv2df3;
>> 
>> etc.
>> 
>> However if you look at insn-flags.h you'll see that
>> These flags mostly have the same definitions
>> 
>> For instance 
>> 
>>> grep "HAVE_while_ult" ../../build-aarch64-none-elf/obj/gcc2/gcc/insn-flags.h
>> 
>> #define HAVE_while_ultsivnx16bi (TARGET_SVE)
>> #define HAVE_while_ultdivnx16bi (TARGET_SVE)
>> #define HAVE_while_ultsivnx8bi (TARGET_SVE)
>> #define HAVE_while_ultdivnx8bi (TARGET_SVE)
>> #define HAVE_while_ultsivnx4bi (TARGET_SVE)
>> #define HAVE_while_ultdivnx4bi (TARGET_SVE)
>> #define HAVE_while_ultsivnx2bi (TARGET_SVE)
>> #define HAVE_while_ultdivnx2bi (TARGET_SVE)
>> #define HAVE_while_ultsivnx16bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultdivnx16bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultsivnx8bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultdivnx8bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultsivnx4bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultdivnx4bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultsivnx2bi_ptest (TARGET_SVE)
>> #define HAVE_while_ultdivnx2bi_ptest (TARGET_SVE)
>> 
>> So we're spending quite a bit of time reading and compiling these files to just set
>> the same flag over and over again.
>> 
>> If we were to group the generated code by the defines instead, we wouldn't
>> need giant array assignments.
>> 
>> Init_all_optabs would just become:
>> 
>> bool *ena = optabs->pat_enable
>> 
>> memset (ena, 0, sizeof optabs->pat_enable);
>> 
>> if (TARGET_SVE)
>>  memset (ena + offset, 1, count);
>> 
>> which I think would be both a runtime and a compile time win because
>> quite a few insn have either no condition, or are just TARGET_SVE or
>> TARGET_SVE2 etc.  And I assume this is common across many other
>> targets.
>> 
>> Though I have only experimented with a small version years ago.
>> 
>> Other files have similar things that interesting to evaluate wrt to the
>> scale the generators are at now.
>> 
> 
> This turned out to not be too hard after all. I’ve tried to factor common code out to gensupport.cc and made this change genopinit. Sent out as a separate series.

I ended up exploring the rest of the gen* generators to find areas where their output could be improved, before we tackle the splitting. I’ve sent out a separate patch series that I think tackles the RTL side of the generators more comprehensively.
Thanks,
Kyrill


> Thanks,
> Kyrill
> 
>> Thanks,
>> Tamar
>> 
>>> 
>>>> 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.
>>> 
>>> Yeah, I added your suggestion to the initial genemit split.  And at
>>> least the "which file to write to next"/ftell functionality is not local
>>> to genemit but already in gensupport.  The function is choose_output and
>>> Kyryll's patch even uses it already so it shouldn't do iterative
>>> splitting if I'm not mistaken.
>>> 
>>> Each gen* still keep track of its own files, though, and that part could
>>> be unified still.  I don't think it's terribly difficult but will
>>> require some plumbing.
>>> 
>>> 
>>> --
>>> Regards
>>> Robin