[tree-ssa] Gimplifying Java

[law@redhat.com]

In message <Pine.LNX.4.44.0306111928540.10620-100000@ops2.one-point.com>, Jeff 
Sturm writes:
 >Following is my first attempt to merge the gcj source frontend with the
 >The other two are apparently caused by wrong code generated in the
 >out-of-SSA pass (insert_copy_on_edge intializes a local variable to an
 >unitialized temporary).
 >
 >I can probably fix the first failure drawing upon several good ideas from
 >the mailing list.  The out of SSA pass is still beyond my comprehension,
 >though I wonder if this isn't related to one of the known shortcomings,
 >such as live range overlapping.  (I do have a test case.)
Well, overlapping live ranges is supposed to work now, so I'm sure 
Andrew would like to have a testcase.


 >With the possible exception of 1) these should be straightforward to fix.
 >Regardless, the patched compiler is good enough to build the runtime and
 >complete the testsuite with only the regressions mentioned above.  I've
 >also built and run some nontrivial Java applications with it.
Very cool.


 >Most of the conversion is handled in java_simplify_expr, however there are
 >other changes due to certain trees that are not acceptable to gimplify
 >even though they are accepted by the RTL expanders.  For example,
 >LOOP_EXPR nodes with trailing empty statements cause an incorrect CFG to
 >be constructed, breaking copy/constant propogation. 
How interesting -- I'm looking at this problem right now.  I managed to
trigger the same bug when we started zapping redundant const calls such
as with this code:

g (int i)
{
}

f (int i)
{
  g (0);
  while ( ({ i--; }) )
    g (0);
}

main ()
{
  f (10);
  exit (0);
}

We know that "g" is pointless, so we replace the second call to "g" with
an empty statement.  This effectively gives us a loop like this

  while (1)
    {
      {
        i.2 = i;
        i = i - 1;
        retval.1 = i.2
      };
      if (retval.1 == 0)
        {
          goto <ULb690>;
        };
      (void)0
    };

Which sounds like the same loop you've run into.  Anyway, we muck up the
CFG and things go downhill from there.

The good news is I'm on this one :-)  I need it fixed before we can start
removing redundant/useless calls to const functions.


 >RTL expansion.  In another case a pointer node is passed as the
 >condition operand of a COND_EXPR, so rewrite_into_ssa propagates a
 >'1' into the 'then' branch as if it were a boolean operand.  Though these
 >may be bugs, the frontend could stand to be a little less sloppy when
 >building trees anyway.  (Does a void SAVE_EXPR ever make sense?)
We've found a few cases there the front-ends are being sloppy -- if it's
easy we try and fix them (and propagate the fix into the mainline).  At
the same time we try to make the gimplifier be tolerant of such sloppyness.

Very very very cool.  Thanks a ton for working on this....

I'll let others chime in on the patch...

jeff