Re: RFC: Java inliner

[Per Bothner <per at bothner dot com>]

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.

Now it may turn out that some of the Java tree representations should
be changed, but switching e.g. to using IF_STMT is a step in the
wrong direction.
--
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/