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. 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. 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 :) Roger --
