在 2020年7月24日 +0800 PM9:19，Segher Boessenkool <seg...@kernel.crashing.org>，写道： > On Fri, Jul 24, 2020 at 12:03:16PM +0200, Richard Biener via Gcc-patches > wrote: > > 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: > > > > +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. > > Yeah, it has to be the same number everywhere. Something high enough > that bigger machines benefit (so 100 or so), but not so high that the > overhead increases too much... It shouldn't be quite as high for > smaller backends... so some fixed ratio of number of define_insns > perhaps, something like that? >
We can get bigger benefit with much more huge file in this simple solution, Indeed, it does not cover smaller backends. Yes, we should consider to target all backends, I thinks there is no high enough benefit for smaller backends, is it necessary ? > Something else. Does this make the generated compiler slower? It will > at least potentially have fewer inlining opportunities, but does that > matter? > Yes, some machine will take > 30 minutes in my testcase, It’s really matter in gcc development stage :( > Thanks for working on this, > > > Segher
