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: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Richard dot Earnshaw at arm dot com, Karel Gardas <kgardas at objectsecurity dot com>, 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 14:38:01 +0100
- Subject: Re: std::pow implementation
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Richard Earnshaw <rearnsha@arm.com> writes:
>
> [...]
>
> | Now, assume that the amount of code in the a!=1 case is reduced. At what
> | point does it become beneficial to always inline? Can the programmer
> | tell?
>
> He can profile.
Profiling doesn't help if the answer comes back as "sometimes" (function
foo's use of bar is best inlined, function wibble's use of bar is best not
inlined).
>
> | Should he write the code in a separate function, or should he leave
> | it to the compiler to decide? What happens if the code is ported to
> | another machine with twice as many registers?
>
> Let's not have the compiler speculate about the future plateform the
> programmer will run his program on -- it has no clue.
And nor, necessarily, can the programmer who writes a class definition.
Don't forget that it may end up being used by other programmers who have
no power to change the class interface.
>
> | With Gaby's suggested interpretation, the compiler has *no* choice; it
> | must obey the inlining constraint because the programmer always knows
> | better... Even when prepared to admit that he doesn't.
>
> That assertion is wrong.
Which bit of it? It's what I understand you to be suggesting.
R.