This is the mail archive of the
mailing list for the GCC project.
Re: generate_bytecode_insn - tree code not implemented: min_expr
- From: Andrew Haley <aph at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Erik Poupaert <erik at poupaert dot hurricanedev dot com dot cambridge dot redhat dot com>, <gcc at gcc dot gnu dot org>, <java at gcc dot gnu dot org>
- Date: Mon, 15 Sep 2003 11:56:00 +0100
- Subject: Re: generate_bytecode_insn - tree code not implemented: min_expr
- References: <Pine.LNX.email@example.com>
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
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.