This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: std::pow implementation
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Bernd Schmidt <bernds at redhat dot com>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, gcc at gcc dot gnu dot org
- Date: 04 Aug 2003 14:03:09 -0300
- Subject: Re: std::pow implementation
- Organization: GCC Team, Red Hat
- References: <Pine.LNX.4.44.0307291353040.14031-100000@bellatrix.tat.physik.uni-tuebingen.de><m3he55tu7y.fsf@uniton.integrable-solutions.net><1059481647.3651.120.camel@steven.lr-s.tudelft.nl><m3wue1se52.fsf@uniton.integrable-solutions.net><1059483328.3651.144.camel@steven.lr-s.tudelft.nl><m34r15scu3.fsf@uniton.integrable-solutions.net><1059487859.3650.208.camel@steven.lr-s.tudelft.nl><m3ptjto1bh.fsf@uniton.integrable-solutions.net><ord6fsbq09.fsf@free.redhat.lsd.ic.unicamp.br><m3fzkofw5r.fsf@uniton.integrable-solutions.net><oru194a8kw.fsf@free.redhat.lsd.ic.unicamp.br><m3llugcydy.fsf@uniton.integrable-solutions.net><orbrvca4x4.fsf@free.redhat.lsd.ic.unicamp.br><m3el08cwlj.fsf@uniton.integrable-solutions.net><oru1948fsh.fsf@free.redhat.lsd.ic.unicamp.br><Pine.LNX.4.55.0308041705370.11639@host140.cambridge.redhat.com>
On Aug 4, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
> We've had -finline-functions (aka -O3) for years; it does what you
> suggest: let the compiler choose which functions to inline. If we
> assume that this option does a reasonable job, it can be used if you
> want to write portable code and don't want to bother with performance
> measurements and suchlike.
I'd promised I'd step away from the debate, but my argument is being
misunderstood, so I'll just clarify. I'm not arguing for the compiler
to disregard inline entirely, in that, if you don't mark a function as
candidate for inlining, the compiler won't even consider the
possibility of inlining. However, if you do, it will evaluate whether
it appears to make sense to inline it in order to improve performance,
or whether the inline marker was there just to make the body of the
function visible for the translation unit, in case inlining was found
to be profitable. Unfortunately, the only way to make the body
visible without violating the ODR is by marking the function as
inline, either with the inline keyword or by defining it inside the
class body.
> I propose that it have the effect expected by most people who aren't
> compiler hackers: let the function be inlined, if possible within
> reasonable limits (*).
We agree here. The trick is to define what reasonable limits are.
Not everybody agrees that it's reasonable to get compile time or
generated code size to explode even if the program would still work.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer