generate_bytecode_insn - tree code not implemented: min_expr

Mon Sep 15 16:57:00 GMT 2003

Roger Sayle writes:
 > 
 > 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.
 > 
 > 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.
Gosh. Well, I find it hard to believe that anything with semantics as
complex as MIN_EXPR can really be considered canonical, but I'll take
your word for it.
 > Given that jcf-write can handle COND_EXPR, it really should be
 > trivial to support MIN_EXPR and MAX_EXPR as well.
Yes it is, but you could say the same about FFS_EXPR and
POPCOUNT_EXPR. And every time someone adds a new one of these we'd
have to add a new case to jcf-write.
 > 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.
I don't understand why you say this. MIN_EXPR and MAX_EXPR are
problematic idioms that the JVM doesn't support.
 > 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.
Of course, but that's a different matter altogether.
 > 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.
Ah, okay. That's a good reason to do this -- but I'd much rather that
the generation of MIN_EXPR and MAX_EXPR be conditionalized on
optimization.
I have no objection at all to making jcf-write support MIN_EXPR and
MAX_EXPR if that's necessary, but I'm sure you appreciate that I don't
want to spend the rest of my days adding new cases each time someone
invents a new kind of expression. These are optimizations, and
there's no need to generate them if we're not optimizing.
It would help if I had a list of all the canonical EXPRs. Then I
could check for them in jcf-write. Even better, if there was an enum
for just the canonical ones I wouldn't need a default label in the
switch and the compiler would barf (when building jcf-write.o) if any
case wasn't handled.
Andrew.