>>>>> "Roger" == Roger Sayle <[EMAIL PROTECTED]> writes:
Roger> The operator BIT_FIELD_REF, for example, can be seen as a Roger> canonical representation of a shift-and-mask or a Roger> mask-and-shift operation. The problem that lead to the creation of the can_use_bit_fields_p lang hook was that fold was turning references to two adjacent fields into a single BIT_FIELD_REF. This confused the bytecode writer, and inverting the transforms done by fold looked tricky. IMO, gcj has always inhabited a sort of grey area here. It has relied on fold() not to do things that jcf-write.c didn't expect. That this assumption breaks from time to time isn't really surprising. In addition to relying on the output of fold() to be acceptable for bytecode generation purposes, gcj has also relied on fold to do the constant folding required by the java programming language. This has also caused problems from time to time; I think there are still open PRs about this (plus hacky little workarounds here and there). Roger> My understanding is that its this failure of the java folks to finish Roger> implementing an expand_expr replacement for JVM bytecodes thats the Roger> primary motivating factor for the new "gcjx" front-end :) Heh. Really my motivation was to have a more maintainable code base for adding the new language features (generics, primarily, but there are others). In particular I was interested in a front end that used static typing instead of 'tree'. In gcjx, the only time we see trees is when we know we want to generate object code. In this situation, anything fold() or other parts of the middle-end decide to do will be ok (with the minimal assumption that they are semantics-preserving transformations). My goal in doing this was to insulate language-mandated parts of gcjx, and non-gcc-related things like bytecode generation, from decisions made in the rest of GCC. The drawback of this approach, as Roger pointed out on irc once, is that sometimes we may lose optimizations. For instance, he wrote a cool jcf-write.c patch to handle RSHIFT_EXPR of unsigned types, which let us generate better bytecode in some situations. But in the end I think this isn't of great consequence -- optimizing java bytecode is not very important (performance sensitive folks use JITs which already do all these optimizations anyway). I would recommend this general approach to anybody writing a GCC front end. It is, to my mind, simpler to write and to maintain. Tom
