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.
