This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Clean up early inliner


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

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

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]