This is the mail archive of the gcc-patches@gcc.gnu.org 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


On Aug 9, 2010, at 7:50 AM, Mark Mitchell wrote:

> Also, I think that the number of instructions combine should consider
> might as well be a --param. ...  Then, distributors
> could set whatever default (2, 3, 4, 5, 100, whatever) they think
> appropriate for their users.
> 
> 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.
...
> 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.

I find this attitude to be really interesting, as the approach was similar in the -fomit-frame-pointer thread.  While it's always easy to add "yet another knob" and push the onus/responsibility back onto distributors, this is problematic in other ways.  In particular, this neutralizes one of the major advantages that GCC has brought to the FOSS world over the last couple decades: it provides a standardized interface to the C compiler which makefiles and programmers know.

I realize that this specific example isn't a big deal, and GCC has more params than normal distributors would actually care about in practice, but the general attitude is interesting.  If nothing else, if the distributor wanted to change something, they could always hack up the source before they ship it.

Is "throw in a param and let the distributors decide" really a great solution to issues like these?

-Chris


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