This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: std::pow implementation


> > (*) 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.

If the user asks for very large functions to be inlined, the user loses.
But the good news is that the fix is easy.

> Of course, the question is
> 
> 1. Does this happen often in practice (certainly as I Have noted before we
> often see that -O3 slows things down compared to -O2: speed = space in the
> land of icaches).

-O3 is irrelevant: with -O3, we ask the compiler to find additional
functions to inline.  The slowdown with -O3 shows that the compiler is
not doing a good job making its own choices.

> 2. Can the compiler really usefully tell this is the case, or does it make
> so many mistakes trying to be helpful in this way that it actually hurts.

See above.

> With regard to the "collapsing code" issue, clearly the best strategy is
> to do parameter substitution and collapse the code *before* deciding whether
> to inline it. Of course this is not so easy to do.

Sigh.  In C++, the programmer has already done the needed analysis, and
has attached the keyword "inline" or defined the function in the class
body.  Certainly, with -O3 the kind of analysis you describe would be
appropriate, though possibly expensive.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]