Op wo 30-07-2003, om 14:22 schreef Richard Guenther:
> On 30 Jul 2003, Gabriel Dos Reis wrote:
> 
> > Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
> >
> > | Of course being able to hint the compiler some more can be useful to
> > | overcome weakness in the compilers inlining decision implementation as
> > | that never will be perfect.
> >
> > It takes first abandoning the idea that the compiler always knows
> > better than the programmer and the programmer's use of "inline" is
> > most of the time nonsensical.  The programmer does provide hint.  The
> > compiler choses not to listen.
> 
> Well, the point is you question that inline should be a hint, but take it
> as the same as __attribute__((always_inline)) is defined. The compiler is
> free to ignore hints if it thinks the hint is against the task it is
> performing (take f.i. a inline declared modestly sized function when
> compiling with -Os).

No, always_inline also implies inlining functions that call alloca, so 
it's a bit stronger than that.

The attached patch makes C++ ignore inline limits if the function was
declared with "inline".  Maybe you can try and see what it does for you?

> I'd argue for the inline keyword makeing the compiler think twice before
> not inlining a function and -finline-functions on by default (if inline is
> a hint to inline, why should no inline force the compiler not to inline?).

That could be done by setting max-inline-insns-single to a larger value
for C++.  This has been discussed many times and your numbers show it
would help, but at an unacceptable cost of compiler speed.  IIRC a lot
of the slowdown was in expand, so with tree-ssa we could give this
another try (assuming tree-inline can clean up a lot of cruft before
expanding...).

Gr.
Steven