Hi! On Wed, Jul 29, 2020 at 05:02:04PM +0800, Jojo R wrote: > 在 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: > > > 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