[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