This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inliner in gcc-3.1
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Cc: Kurt Garloff <garloff at suse dot de>, <gcc at gcc dot gnu dot org>,Andreas Jaeger <aj at suse dot de>
- Date: Tue, 30 Apr 2002 10:48:56 -0400 (EDT)
- Subject: Re: inliner in gcc-3.1
> MSTDir[V=13,A=40]| 25.62 | 24.44 | 20.71 | 19.91 |
> MSTDir[V=15,A=40]| 25.70 | 24.47 | 20.72 | 19.93 |
> MSTUndir[V=13,A=40]| 12.89 | 12.82 | 11.15 | 10.72 |
> MSTUndir[V=15,A=40]|214.53 |210.60 |182.74 |176.79 |
> TIMETABLING| 9.61 | 10.71 | 10.51 | 10.29 |
>
> That is, code quality improves measurably overall and this would be a
> patchset that would be nice to have on mainline, after the first one
> RTH approved in principle, and which is just needing minor polishing,
> went in.
>
> > I'd be curious what other people get.
>
> Regardless of all these benchmarks, I believe one major problem the
> currently inliner has is that it's way too slow and thus forces us to
> default to inline limits which are too small to generate really efficient
> code for deeply nested C++ structures.
It's not the inliner, it's the expanders and things that aren't
particularly quick, like CSE.
But, I actually wanted to see if other compilers had the same issue (if
you kick up the inline limits, they become very slow), and sure enough,
they do.
If I kick the inline limits up on Intel's C++ compiler, it starts to take
5-10 minutes on code it could compile in 10 seconds.
This is with both C, and C++.
It also just makes the binaries bigger, not faster.
This was about a week ago that I did this, it was just a curiosity, so I
didn't sit there and make tables or anything.
I could, if anyone cares.
>
> Gerald
>