RFC: Java inliner

[Andrew Haley]

Per Bothner writes:
 > Mark Mitchell wrote:
 > > The right thing to do is clear: convert the Java front end to use trees
 > > that are more like the C/C++ trees.
 > 
 > Let us recap:
 > 
 > (1) Gcc orignally has a set of generic tree codes designed to be
 > more-or-less language-independent.
 > (2) Java carefully adds a few new tree codes in the sprit of the
 > original, re-using existing tree-codes where it makes sense, for example
 > using COMPOUND_EXPR for (e1; e3;) and COND_EXPR for if-then-else.
 > (3) The C++ people add a whole new slew of tree-codes that are
 >    (a) redundant, and
 >    (b) less general and only suitable for C/C++ (e.g. not it appears
 >    useful for expression languages).
 > (4) The C++ people want the Java people to switch to using their
 > tree-codes, and say this is "the right thing to do".
 > 
 > I beg to disagree.
 > 
 > I believe the right thing to do in the short term is extend the C/C++
 > inliner to understand the Java trees.  Almost all of the tree codes 
 > encountered will be generic tree codes defined in tree.def.  There are
 > some tree-codes in java-tree.def; most of these are specific to parse.y,
 > and will have disappeared by the time they reach the inliner.

I agree.  

Java needs an inliner.  It seems to me completely crazy to convert the
front end to require Java to use C++ trees in order to get it.

I'm going to look at doing what Per suggests.  If it turns out not to
be a clean patch I'll abandon the idea.

Andrew.