RE: -finline-functions does not affect libstdc++?

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On Mon, 27 Oct 2003, Chris Lattner wrote:

> On Mon, 27 Oct 2003, Richard Guenther wrote:
> > > This is because almost all of libstdc++ is specified in terms of
> > > "external" templates.  For example, ostream and istream all use external
> > > templates, so the compiler does not instantiate them except when building
> > > libstdc++.  Presumably this is a performance optimization of the compiler
> > > itself, rather than of the code.
> >
> > Hm, the failed to inline functions are actually in the headers, but not
> > marked inline. So I still think -finline-functions does not affect
> > libstdc++ declarations.
>
> Can you give some examples?

Of course, like

bits/stl_uninitialized.h:83
_ForwardIterator std::__uninitialized_copy_aux(_InputIterator,
_InputIterator, _ForwardIterator, __false_type)

or

bits/stl_uninitialized.h:187
_ForwardIterator std::__uninitialized_fill_n_aux(_ForwardIterator, _Size,
const _Tp&, __false_type)

also

ext/pool_allocator.h
static void* __gnu_cxx::__pool_alloc<__threads, __inst>::allocate(size_t)

and others from .tcc files (which you meant presumably with "external"
ones?) like

bits/vector.tcc
std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const
std::vector<_Tp, _Alloc>&)


> > But, I doubt so much changed between 3.3 and 3.4 in this area. So there
> > must be something seriously wrong with 3.4s loop/gcse/cse passes that they
> > leave all this crap in, compared to 3.3. Ugh. I'll try to dig into it -
> > but 223 lines assembly for 3.3 compared to 531 for 3.4 is just bad.
>
> Remember that 3.4 has a different libstdc++ also.

Of couse. I just get a lot of the above in my inner computation loop and
am not very happy about this ;) gcc3.3 either could inline them and then
optimize them away, or not generate them in the first place.

Richard.