Re: [RFC] fold Reorganization Plan

[Andrew Haley <aph at redhat dot com>]

Roger Sayle writes:
 > 
 > On Tue, 15 Feb 2005, Andrew Haley wrote:
 > > There's one other thing to bear in mind when considering the way that
 > > fold relates to language front ends.  We've seen problems in Java
 > > where fold() returned tree nodes that Java didn't recognize: one time,
 > > for example, it returned a BITFIELD_EXPR.
 > 
 > I see the current java front-end's inability to lower standard tree
 > nodes in to JVM bytecodes as a failing of the gcj implementation
 > rather an intrinsic problem in the constant folder.  The operator
 > BIT_FIELD_REF, for example, can be seen as a canonical representation
 > of a shift-and-mask or a mask-and-shift operation.  Hence, should
 > the tree-ssa analysis passes prefer to see "(x & 12) >> 2" or
 > "(x >> 2) & 3" as BIT_FIELD_REF (x, 2, 2), it should be a relatively
 > trivial task for jcf-write.c to convert BIT_FIELD_REF (x, 2, 2) back
 > into an ishr/iand sequence.

Well, okay.  If bitfields are to be declared language independent, I
won't argue.  But there's a more general point here: if a language
doesn't have pointers, for example, must its front end cope with them
just in case fold() decides to return one?

 > Exactly, the same problems were claimed with jcf-write's inability
 > to handle ABS_EXPR, MIN_EXPR, MAX_EXPR, NOP_EXPR, RSHIFT_EXPR, etc...
 > 
 > The design decision made by gcj was that rather than to provide a
 > JVM back-end target, was to instead side-step GCC's RTL expansion
 > and perform the lowering to Java bytecodes itself.  As such, any
 > RTL expansion functionality that failed to get implemented in gcj
 > would appear to be a short coming of the java front-end, i.e. a
 > sorry(), rather than a bug or problem in fold or the middle-end.

The gcj bytecode writer isn't really the primary issue, as far as I
can see.  It's whether every front end must handle all of the possible
tree nodes, when some of those nodes cannot arise during parsing of
the source language.

 > My understanding is that its this failure of the java folks to finish
 > implementing an expand_expr replacement for JVM bytecodes thats the
 > primary motivating factor for the new "gcjx" front-end :)

Er, that is not my understanding.  The primary primary motivating
factor for gcjx is a parser that's easier to expand with new langauge
constructs and, of course, to maintain.

Andrew.