Re: inliner in gcc-3.1

[Daniel Berlin <dberlin@dberlin.org>]

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