This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fobey-inline (was Re: gcc and inlining)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: Mike Stump <mrs at apple dot com>, Stuart Hastings <stuart at apple dot com>, Matt Austern <austern at apple dot com>, Ron Price <ronp at apple dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Thu, 13 Mar 2003 09:54:05 +0000
- Subject: Re: -fobey-inline (was Re: gcc and inlining)
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> On Wed, 12 Mar 2003, Mike Stump wrote:
>
> > On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> > > I finally got the patch work for C++ (see attached patch - maybe
> > > completely bogous, though...). An I have some numbers for you:
> >
> > If you could, find the various flags that control inlining, and bump
> > the numbers up until you get similar number to (or better than) this
> > flag. Then tell us what those numbers were, then we can consider
> > upping those numbers. Also, tell us the language, I assume it was C++.
>
> I think the problems come from the fact we dont do backwards inlining
> and my code (Pooma, lots of recursive template metaprogramming) is no
> good measure for general applicable inlining limits (at least in the
> current gcc metric). So I suspect if we up the limits so I get decent
> code, others would be seriously suffering.
Backwards inlining is now possible on the trunk thanks to Jan's
unit-at-once work.
>
> But anyway - I'll try and report them.
>
> Oh - I still like this patch or some equivalent to be included in gcc 3.3
> of course ;)
I still think this is a bad idea. Please start thinking about how to
produce a better nut cracker rather than a larger sledge hammer.
R.