Re: generate_bytecode_insn - tree code not implemented: min_expr

[Roger Sayle <roger at eyesopen dot com>]

Andrew Haley writes:
> Erik Poupaert writes:
>
> > In an attempt to compile org-xbill-DNS-1.4.1 natively, I bumped into a
> > strange error message:
> >
> > err>org-xbill-DNS-1-4-1/src/org/xbill/DNS/Name.java:806: error:
> > internal error in generate_bytecode_insn - tree code not implemented:
> > min_expr
> >
> > Does anybody know what it is?
>
> Oh hell, someone's broken fold() again.
>
> Can you extract a test case?  If you can, send it to me and I'll fix the
> bug.

Hi Andrew,

I don't believe that its necessarily "fold" at fault.  The middle-end
considers MIN_EXPR and MAX_EXPR nodes the be the canonical form of
certain forms of COND_EXPR.  Given that jcf-write can handle COND_EXPR,
it really should be trivial to support MIN_EXPR and MAX_EXPR as well.
Whilst I sympathize for the java folks unhapiness with "fold" generating
problematic idioms that the JVM doesn't support, MIN_EXPR and MAX_EXPR
aren't amongst them.

For example, I'm not sure if you've noticed but java/builtins.c creates
MIN_EXPR and MAX_EXPR tree nodes to "inline" java.lang.Math.min and
java.lang.Math.max respectively.

On the positive side, gcj gets several additional optimizations
based upon the commutative and associative properties of min and
max, that aren't applicable to generic COND_EXPRs.  And with native
compilation, you get to use the machine instructions available on
PowerPC and other platforms that provide min and max instructions.

I'm sure you understand the bytecode sequence necessary to implement
MIN_EXPR and MAX_EXPR better than I do, but if there's anything I can
do to help...

Roger
--