Re: generate_bytecode_insn - tree code not implemented: min_expr

[Roger Sayle <roger at eyesopen dot com>]

Hi Tom,

On 13 Sep 2003, Tom Tromey wrote:
> gcj works strangely here.  We build somewhat different trees when
> generating bytecode, and the bytecode writer only recognizes a certain
> subset of tree expressions.  The problem isn't so much changing gcj to
> recognize something new, but rather that any change can potentially
> cause problems.

Ah, understood.  The best way to work around the producer-consumer
deadlock is to improve jcf-write adding support for tree nodes that
may never occur.  This is initially very safe, as the code is never
triggered, but it should also ease the fears of those upstream about
which nodes they can or can't use.


> I think we shouldn't be using fold() here, anyway.  fold() doesn't
> respect the Java rules for constant folding (as far as I know), and we
> still have a lot of bugs in this area...  Unfortunately, changing this
> is pretty substantial, and nobody has volunteered.

I've volunteered and have fixed several problems (for example, -fwrapv).

The last time I asked Andrew, the only remaining constant folding problem
that he was unsure of was something to do with generating bitfield
references.  Unfortunately, he couldn't remember the specifics so I
haven't been able to fix it.  There are also no middle-end PRs that
mention java semantics, TTBOMK.  So apart from whereever field accesses
are constructed, the rest of the java front-end should be calling "fold"
almost everytime it calls "build".

My apologies if the remaining issues are all listed in bugzilla as java
(front-end) PRs.  Unless some when brings them to my attention, I might
never fix them.  And unless I contend that "fold" is (attempts to be)
java-safe, the java-folks might never realize that everything has been
fixed.

> In the meantime, it wouldn't be hard for someone to change jcf-write
> to handle MIN_EXPR and MAX_EXPR.

Agreed.

> Roger> For example, I'm not sure if you've noticed but java/builtins.c
> Roger> creates MIN_EXPR and MAX_EXPR tree nodes to "inline"
> Roger> java.lang.Math.min and java.lang.Math.max respectively.
>
> This code should never be run when generating bytecode.

That's a pity, constant folding things like "Math.sqrt(4.0)" should
benefit byte code interpreters as much as it helps native compilation.
jcf-write only needs to translate surviving calls to builtin decls
back to the original method reference.

[Come to think of it, bit field references might also be a failing of
jcf-write's ability to turn things back into shifting and masking ops].

As before, let me know if there's anything I can do.

Roger
--