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


On 30 Jul 2003, Steven Bosscher wrote:

> 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?

It does no good, as it is certainly worse than #define inline
__attribute__((always_inline)) and that made compile times and code size
go through the roof last time I checked, but read on ...

> > 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.

Note that with recent function size estimate changes and callgraph
inlining the world is very much better now.

Tuning the limits doesnt help the semantic misbalance of the inline hint
which is a hint for inlining only, but omitting it is an order not to
inline (if -finline-function is not specified, otherwise its meaningless
anyway). Oh - and we have -fno-default-inline, too, which I think we
should drop as it seems to be against the quoted standards.

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

Yes, these problems were fixed with patches from Mark and the callgraph
stuff from Jan. The things left are the ability to fine-tune inlining like
suggested in another post:

- #pragma inline
- #pragma noinline
- #pragma inline complete  or  __attribute__((leafify))

most compilers for HPC platforms support these notions and they are indeed
useful.

Richard.



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