This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Combine four insns

Jeff Law wrote:

>> Yes.  Such combiner bridges may still be useful to help with five-insn
>> combinations :)

> Yea, though I expect there to be an ever-decreasing payoff for allowing
> larger bundles of instructions to be combined.

We all agree that faster compilers are better, all other things equal.
There was a suggestion for a heuristic that might speed up things
considerably without losing many opportunities, and Bernd thought that
was a good idea.  Perhaps that will get back most of the time and this
discussion will be semi-moot.

Also, I think that the number of instructions combine should consider
might as well be a --param.  As far as I can tell, it would be
reasonably easy to modify the pass to pass around an array of
instructions to combine, rather than i0, i1, i2, i3.  Then, distributors
could set whatever default (2, 3, 4, 5, 100, whatever) they think
appropriate for their users.  Bernd, is this something that you could do

We still have to have the argument about FSF GCC, but it would be
trivial for a distributor (or even an end user building from source) to
adjust the default as they like.  And, furthermore, it would allow
people to make this trade-off at run-time, independent of the default.
I think it would also make the algorithm clearer.

As to the more general question of compile-time vs. optimization, I
think it's clear that to CodeSourcery's customer base the latter matters
more than the former -- but only up to a point.  Few people want 100%
more compilation time in order to get 0.01% more performance.  But, many
people would happily take 10% more compilation time to get 1% more
performance, and almost all would accept 1% more compilation time to get
1% more performance.

Like Bernd, I doubt that compilation time with optimization enabled per
se is the dominant concern for most people.  GCC's own build times are
increasingly dominated by configure scripts, make overhead, and linking.
 Incremental linking would probably do more to improve the typical
programmers compile-edit-debug cycle (which is probably done with -g,
not -O2!) than anything else.  Compile-time improvements at -O2 benefit
distributors or others who are doing builds of massive amounts of
software, but I'm skeptical that GCC is getting slower faster than
hardware is getting cheaper.

So, I think that combining four instructions by default is plausible.
But, defaults are always arguable.  I think that for FSF GCC we
shouldn't spend too much time worrying about it.  The userbase is too
diverse to make it easy for us to please everybody.  Make it easy for
distributors and let them pick.  They have a better chance of getting
things set up correctly for their users, since their users are a
narrower set of people.

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]