This is the mail archive of the
mailing list for the GCC project.
RE: -finline-functions does not affect libstdc++?
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 27 Oct 2003 19:55:04 +0100 (CET)
- Subject: RE: -finline-functions does not affect libstdc++?
- References: <Pine.LNX.firstname.lastname@example.org>
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
_InputIterator, _ForwardIterator, __false_type)
_ForwardIterator std::__uninitialized_fill_n_aux(_ForwardIterator, _Size,
const _Tp&, __false_type)
static void* __gnu_cxx::__pool_alloc<__threads, __inst>::allocate(size_t)
and others from .tcc files (which you meant presumably with "external"
std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const
> > 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.