Re: gcc and inlining

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

[from private discussion about the -fobey-inline patch by Stuart Hastings]

On Fri, 7 Mar 2003, Stuart Hastings wrote:

> On Friday, Mar 7, 2003, at 14:39 US/Pacific, Richard Guenther wrote:
>
> > Ok, some tests show no difference in generated code with/without
> > -fobey-inline and the .s files still show calls to methods marked
> > inline.
> > So I suspect somehow this machinery doesnt work for methods of C++
> > template classes (at least).
> >
> > Any idea?
>
> Sorry, no; the inliner has changed considerably since I last worked on
> it (scare yourself: % grep INLINER_FOR_JAVA tree-inline.c).  The
> original inliner had it's go/no-go decision all in one place, and as
> GCC evolves, these decisions tend to spread out.  All "-fobey-inline"
> did was to pretend that "inline" was the same as "__attribute__
> ((always_inline))", and that used to be "enough."  Somewhere, somebody
> else is vetoing the inlines you want, and I'd need a testcase, a
> debugger, and some time to figure out what's happening.

I see more occurances of lookup_attribute("always_inline",...) in gcc
sources, notably the ones in c-objc-common.c:c_cannot_inline_tree_fn,
cp/tree.c:cp_cannot_inline_tree_fn
langhooks.c:lhd_tree_inlining_cannot_inline_tree_fn, related
to flag_really_no_inline, perhaps the attribute lookup check needs to be
changed to honour DECL_DECLARED_INLINE_P, too?

Also langhooks.c:lhd_tree_inlining_disregard_inline_limits looks like it
wants to be changed like the patched
c-objc-common.c:c_disregard_inline_limits.

As I cannot do regression checks here I'm not very keen on changing all
the above without some "yeah - seems safe to try this" from someone ;)

Thanks, Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/