On 5/2/19 3:18 PM, Richard Biener wrote: > On Mon, 29 Apr 2019, Martin Liška wrote: > >> On 9/10/18 1:43 PM, Martin Liška wrote: >>> On 09/04/2018 05:07 PM, Martin Liška wrote: >>>> - in order to achieve real speed up we need to split also other generated >>>> (and also dwarf2out.c, i386.c, ..) files: >>>> here I'm most concerned about insn-recog.c, which can't be split the same >>>> way without ending up with a single huge SCC component. >>> >>> About the insn-recog.c file: all functions are static and using SCC one ends >>> up with all functions in one component. In order to split the callgraph one >>> needs to promote some functions to be extern and then split would be >>> possible. >>> In order to do that we'll probably need to teach splitter how to do >>> partitioning >>> based on minimal number of edges to be removed. >>> >>> I need to inspire in lto_balanced_map, or is there some simple algorithm I >>> can start with? >>> >>> Martin >>> >> >> I'm adding here Richard Sandiford as he wrote majority of gcc/genrecog.c >> file. >> As mentioned, I'm seeking for a way how to split the generated file. Or how >> to learn the generator to process a reasonable splitting. > > Somewhen earlier this year I've done the experiment with using > a compile with -flto -fno-fat-lto-objects
-fno-fat-lto-objects is default, isn't it? > 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. Can you please provide exact command line how to do that? > > Adding other files to this handling looks trivial as well, as well > as conditionalizing it (I'd probably not want this for devel builds). > > It might be interesting to optimize this a bit as well by somehow > merging the compile and WPA stages, thus special-casing single TU > WPA input in a similar way as we (still) have -flto-partition=none. > > That said, re-doing the measurement is probably interesting (as > applying to other cases like insn-recog.c). > > Richard. >
