在 2020年7月24日 +0800 PM6:03，Richard Biener <richard.guent...@gmail.com>，写道： > On Fri, Jul 24, 2020 at 10:13 AM Rainer Orth > <r...@cebitec.uni-bielefeld.de> wrote: > > > > Jojo R <jiejie_r...@c-sky.com> writes: > > > > > gcc/ChangeLog: > > > > > > * genemit.c (main): Print 'split line'. > > > * Makefile.in (insn-emit.c): Define split count and file > > [...] > > > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > > > index 2ba76656dbf..75841e49127 100644 > > > --- a/gcc/Makefile.in > > > +++ b/gcc/Makefile.in > > > @@ -1253,6 +1253,13 @@ ANALYZER_OBJS = \ > > > # We put the *-match.o and insn-*.o files first so that a parallel make > > > # will build them sooner, because they are large and otherwise tend to be > > > # the last objects to finish building. > > > + > > > +insn-generated-split-num = $(shell grep -c ^processor /proc/cpuinfo) > > > > This is highly unportable, probably Linux-only. It certainly doesn't > > exist on at least Solaris and macOS. Maybe gnulib has something here. > > It will also produce different build results depending on the build host > which is even more undesirable. >
Theoretically possible it’s the highest performance for building insn-emit.c if all processors are used. User should not pay much more attention at auto-generated file like insn-emit.c, it’s right ? > Richard, > > > Rainer > > > > -- > > ----------------------------------------------------------------------------- > > Rainer Orth, Center for Biotechnology, Bielefeld University
