This is the mail archive of the
mailing list for the GCC project.
Re: std::pow implementation
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Scott Robert Ladd <coyote at coyotegulch dot com>
- Cc: Richard dot Earnshaw at arm dot com, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Alexandre Oliva <aoliva at redhat dot com>, Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, gcc at gcc dot gnu dot org
- Date: Wed, 30 Jul 2003 17:29:11 +0100
- Subject: Re: std::pow implementation
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Richard Earnshaw wrote:
> > This is talking specifically about *very small* functions ("one or two
> > assignments"). It says nothing about what happens if the programmer
> > decides to put a 2000 line monstrosity in the middle of a class definition
> > (which would be legal, if somewhat stupid). A practical compiler
> > eventually has to say "enough is enough", or it is likely to crash, run
> > out of memory or whatever.
> I do not want my freedom limited by the stupidity of others. If someone
> explicitly inlines a 2000-line function, let them; the wisdom of such a
> choice (or lack thereof) is an issue for code review and the marketplace.
> Let's say that I use a little shell sort in a program; should the
> compiler decide to replace my explicit choice of algorithm with
> quicksort, even though I have determined that shell sort is better?
> When I say "inline", I mean inline, regardless of other opinions
> (including those of the compiler).
Really? And when you say "register" do you really mean that? If so, then
I'm sorry, but you are in for a big disappointment when using gcc -- it
completely ignores the register keyword when optimizing and has done since
> > I disagree. What really counts is that the compiler has sufficient
> > information to do a good job when compiling the code (ie to reduce, and
> > hopefully eliminate, the abstraction penalty). What constitutes a "good
> > job" is up to the compiler...
> What constitutes a "good job" is defined by a human mind, not a piece of
> technology that lacks any concept of "good." Over the years, I've found
> many arrogant tools (and not just from Microsoft) -- tools that assume,
> *incorrectly*, that their "wisdom" exceeds mine.
I've already given examples of when the compiler can make use of context
to give better inlining than can be determined statically. Your
"arrogant" assertion that inline must always and unconditionally mean
inline impliess that programmers can never take advantage of those cases.