This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Clean up early inliner
On Fri, 9 Apr 2010, Jan Hubicka wrote:
> > On Wed, 7 Apr 2010, Jan Hubicka wrote:
> >
> > > Well, if you make the patch to pass testing, consider it preaproved. We can handle
> > > all this stuff incrementally.
> >
> > I looked into the issues and
> >
> > FAIL: gcc.dg/always_inline3.c (test for warnings, line 5)
> > FAIL: gcc.dg/always_inline3.c (test for excess errors)
> >
> > is because we rebuild the cgraph all the time and so lose non-inline
> > reasons set by early inlining (we expect "recursive inlining" but
> > get "not considered for inlining").
>
> Hmm, there is no way to hold this...
> >
> > Also I get
> >
> > FAIL: gcc.dg/tree-ssa/inline-2.c (test for excess errors)
> >
> > It seems we do not consider always_inline functions at all from
> > the greedy inliner? Why? Thus, the following fixes all fails
>
> Hmm, I guess because they should be already all inlined by the code you removed
> so I did not considered it important to populate heap with those ;)
Indeed, the IPA inliner had a loop inlining all always-inline functions
which I removed (because all originally non-indirect calls are already
handled by the early inliner).
> > for me:
>
> Well, then you will get wrong diagnostic claiming that function is too large
> instead of the real problem when you add something long into the function in
> testcase.
>
> I guess we can get around by teaching cgraph_check_inline_limits and
> default_inline_p to be lax for always_inlines so the real inliner will
> re-insert all remaining always inline into heap and work out real reasons for
> those.
Well, I expected that the various cost functions honor
disregard_inline_limits properly. If they don't we indeed need to fix
them.
Richard.