[PATCH v3] genemit.c (main): split insn-emit.c for compiling parallelly
Segher Boessenkool
segher@kernel.crashing.org
Wed Jul 29 14:44:02 GMT 2020
Hi!
On Wed, Jul 29, 2020 at 05:02:04PM +0800, Jojo R wrote:
> 在 2020年7月24日 +0800 PM9:19,Segher Boessenkool <segher@kernel.crashing.org>,写道:
> > On Fri, Jul 24, 2020 at 12:03:16PM +0200, Richard Biener via Gcc-patches wrote:
> > > 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 ?
It should work everywhere. It does not matter much at all how much it
can speed up tiny backends, but there is a large spread in how big the
bigger backends are, too. So either we make it adjust itself, or we
will have to tune it manually, and continuously.
> > 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 :(
That wasn't really my question (or I don't understand your answer).
Segher
More information about the Gcc-patches
mailing list