This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Joe Buck <jbuck at synopsys dot com>
- Cc: Robert Dewar <dewar at gnat dot com>, aoliva at redhat dot com, bernds at redhat dot com, gcc at gcc dot gnu dot org, gdr at integrable-solutions dot net, rguenth at tat dot physik dot uni-tuebingen dot de, s dot bosscher at student dot tudelft dot nl, Richard dot Earnshaw at arm dot com
- Date: Mon, 04 Aug 2003 18:54:27 +0100
- Subject: Re: std::pow implementation
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > > (*) Reasons why I'd accept inline not being honoured:
>
> On Mon, Aug 04, 2003 at 12:53:09PM -0400, Robert Dewar wrote:
> > I would add
> >
> > - doing the inlining as requested increases both the space and execution time
> > of the program, the former very substantially.
>
> Nope. It is appropriate for the compiler to do what the user said. In
> C++, inline functions are for the most part so tiny that the inlined
> function takes up less space than the call. Having the compiler compute
> metrics for all these functions in an effort to second-guess the
> programmer only slows the compiler down.
Not necessarily. The benefit might be more than repaid in terms of less
time spent in CSE if the function turned out to be large.
> If the user asks for very large functions to be inlined, the user loses.
> But the good news is that the fix is easy.
Think portability. Having to change the code every time you compile on a
different platform breaks the whole concept of using high-level languages
to get away from the machine abstraction.
The issue here isn't what to do with really tiny functions, or even what
to to with really enormous ones: it's entirely to do with the boundary
between the two -- how does the compiler decide that it has crossed from
one to the other? A smart compiler can work that out based on its
knowledge of the machine. A dumb one can't. Do we want gcc to be smart
or dumb?
R.