Re: [tree-ssa][rfc c++/cgraph] clean up some java inlining cruft

[Jan Hubicka <hubicka at ucw dot cz>]

> The documented reason for forcing the inlining to fail is no longer
> true -- we have by this point gimplified the function.
> 
> This was my first attempt to cure the aforementioned test failures.
> Cgraph had decided that the function in question could be inlined,
> but then the inliner failed to actually inline.
> 
> This, incidentally, seems like a nasty hole in cgraph that it can't
> see this and reset its expectations about whether an out-of-line copy
> is necessary.
I was told that in Java we always output out-of-line copy to make
runtime interpreters possible, so I believe this problem should never
arrise for Java, unless we start doing serious work on -fwhole-program.

I don't think cgraph should have mechanizm to update it's decisisons.
We simply should have mechanizms to precisely decide when inlining is
possible in advance and do good decisisons at first place.
I think Java is the only exception and it is exception for not very good
reason.

In the case we really need to reset the decisions here, I will implement
the logic for mainline (it used to be there), but I would like to not
merge it into tree-ssa branch.  (or remove immediately after the merge)
> 
> Although it seems to me this hook seems the wrong place to abort the
> inlining process.  There is one more instance of this hook in the C++
> front end.  It appears to be related to errors in templates so perhaps
> it doesn't really matter.  Still, I think the hook should be re-thought.

This hook should be safe, because it either does what expected or
produce error.  It looks broken to produce error this way, but I suppose
this is only for sanity cecking of C++?

Thanks for looking into this!  It seems to me that the Java patch is
good thing to do (at least from cgraph point of view). However I would
like to understand why this breaks something as we may need to update
mainline too.

Honza