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: dewar at gnat dot com (Robert Dewar)
- Cc: aoliva at redhat dot com, gcc at gcc dot gnu dot org, rguenth at tat dot physik dot uni-tuebingen dot de, s dot bosscher at student dot tudelft dot nl
- Date: 30 Jul 2003 15:58:52 +0200
- Subject: Re: std::pow implementation
- Organization: Integrable Solutions
- References: <20030730134614.2C021F2DFE@nile.gnat.com>
dewar@gnat.com (Robert Dewar) writes:
| > Defining a function inline is not a careless action. If inlining
| > isn't profitable, the programmer will profile et remove the inline
| > definition. You don't know better than the programmer.
|
| This is often incorrect, because often code is written to be portable, and
In which ways are you seeing portability here -- apart from the lock-in
syntax __attribute__((__always_inline__))?
The meaning of "inline" here is for C++, not for all languages
supported by GCC.
Programming in C++, especially using its standard library or libraries
using STL-like style -- which happens more often than you might
imagine -- relies on inlining.
| the decision on what is profitable to inline is target dependent. Furthermore
| deciding whether something is profitable to inline on a given target requires
| detailed knowledge of the target architecture, knowledge that very few
| programmers have these days.
But the fact is that the compiler is not doing better by going its own
programmed logic. We've not reached the same level of sophistication
as for register allocation.
-- Gaby