This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inlining failed
> Sat Sep 06 2003, Jan Hubicka wrote:
> > > On Saturday 06 September 2003 19:44, Andreas Jaeger wrote:
> > > > Gunther Piez <gpiez@web.de> writes:
> > > > > After adding a '--param max-inline-insns-single=500' everything now gets
> > > > > inlined like I want, even with my rusty old gcc 3.4 20030903 :-)
> > > >
> > > > The patch also implements better heuristics, try adding
> > > > -funit-at-a-time to your compiler to see them in effect.
> > >
> > > After adding -funit-at-a-time and compiling all sources together, once again
> > > some inline functions were not inlined. And after forcing them to be inlined
> > > with ((always_inline)) some others were not inlined. Just like I hit the
> > > 'max-inline-insns' limit, but even setting it to ridiculous high values
> > > yields no effect, the functions were still 'exlined'. So I ended up with
> > > ((always_inline)) for every function I want to get inlined, as before.
> > > But this is still with gcc-3.4 20030903, i will try it again with a fresh
> > > checkout.
> >
> > There are another arguments limiting overall compilation unit growth and
> > growth of very large functions to limit exponential growth on some C++
> > programs. It is likely that you are fixing one of these.
>
> But this is C source not C++, so why should some some limits for
> C++ stop the compiler? C simply isn't C++. (I know this is common
> middle-end code, still, I think thisis a valid question.)
The problem is common for C++ but it does exist for C as well, you just
need large compilation units. For instance if you use intermodule
optimization with current GCC you get enought inlining candidates to hit
the limits too.
How large your file is? Would be possible to have preprocessed file for
one of cases you see inlining failure?
Honza
>
> --
> H?kan Hjort
>
>
>
>