This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: Richard dot Earnshaw at arm dot com, Karel Gardas <kgardas at objectsecurity dot com>, Alexandre Oliva <aoliva at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: 30 Jul 2003 16:31:47 +0200
- Subject: Re: std::pow implementation
- Organization: Integrable Solutions
- References: <Pine.LNX.4.44.0307301624400.561-100000@goofy>
Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
| > | The only sane possible semantics I see are:
| > |
| > | 1. inline declared functions are inlined always if technically possible
| > | 2. the inline keyword has no effect
| > | 3. inline is handled in an implementation defined manner (as stated in the
| > | standard), maybe by adjusting the set of functions considered for inlining,
| > | as gcc does.
| >
| > I'm arguing for #1 and #3 combined. Meaning, inline simple functions
| > at low optimization level, try hard at higher level + compiler
| > parameter adjustement.
|
| Thats what we have now - generally we go with #3, for small functions we
| go with #1 (tune what is small with --param min-inline-insns=XXX).
What I'm arguing for is not what have. For example, something like
'std::string() const' does not need fiddling with --param -- that is,
its inlining should not depend on the context of use.
-- Gaby