[tree-ssa] Gimplifying Java

Tue Jun 17 18:29:00 GMT 2003

What fun! I'm making good progress gimplifying the bytecode compiler.
I can turn
 public void z(java.util.Map y)
 {
 NN (2);
 int z = zz;
 try3 xxyy = new try3();
 for (int i = 0; i < 10; i++)
 z += NNN (i);
 }
into 
Method void z(java.util.Map)
 0 aload_0
 1 iconst_2
 2 invokevirtual #27 <Method int NN(int)>
 5 pop
 6 getstatic #11 <Field int zz>
 9 istore_2
 10 new #2 <Class try3>
 13 dup
 14 invokespecial #31 <Method try3()>
 17 astore_3
 18 iconst_0
 19 istore 4
 21 iload 4
 23 bipush 10
 25 if_icmpge 42
 28 iload_2
 29 iload 4
 31 invokestatic #33 <Method int NNN(int)>
 34 iadd
 35 istore_2
 36 iinc 4 1
 39 goto 21
 42 return
into
try3.z(java.util.Map) (this, y)
{
 struct try3 * T.3;
 struct 
 {
 struct java.lang.Class * class;
 void * methods[2];
 } * T.4;
 void * * T.5;
 void * T.6;
 try3:: * T.7;
 struct java.lang.Class * try3.8;
 struct try3 * T.9;
 {
 <unnamed type> *.LJpc=42 = ;
 <unnamed type> *.LJpc=21 = ;
 <unnamed type> *.LJpc=0 = ;
 struct try3 * <UV2f50>;
 <UV2f50> = this;
 T.3 = <UV2f50>;
 T.4 = T.3->vtable;
 T.5 = T.4 + 28B;
 T.6 = *T.5;
 T.7 = (try3:: *)T.6;
 <UV50e0> = T.7 (T.3, 2);
 {
 int z;
 z = zz;
 {
 struct try3 * xxyy;
 try3.8 = &try3.class;
 <UV5230> = _Jv_AllocObjectNoFinalizer (try3.8, 4);
 <UV5310> = <UV5230>;
 <UV5230> = <UV5310>;
 T.9 = <UV5310>;
 <init> (T.9);
 xxyy = <UV5230>;
 {
 int <UV5700>;
 int <UV5620>;
 int <UV5460>;
 int i;
 i = 0;
 *.LJpc=21;
 <UV5460> = i;
 <UV50e0> = <UV5460>;
 <UV5540> = 10;
 if (<UV50e0> >= <UV5540>)
 {
 goto *.LJpc=42;
 };
 <UV5620> = z;
 <UV5700> = i;
 <UV50e0> = <UV5620>;
 <UV5540> = NNN (<UV5700>);
 z = <UV50e0> + <UV5540>;
 i = i + 1;
 goto *.LJpc=21;
 }
 }
 };
 *.LJpc=42;
 return;
 }
}
which is (believe it or not) correct, except for a minor gotcha in
that the local variable 'z' is not being SSAd - as you can see it's
initialized twice in this method. I have no idea why.
You may have noticed :-) that there is a ton of unnecessary
temporaries. That's bad of course, but I'll look at that later. The
main reason for these temporaries in the Java compiler is that the gcc
is very prone to rearranging expressions. I presume that SIMPLE won't
do that, so I can remove some of them.
Also, I have no idea why labels are attached to the local variables
list of each block, but I guess that's trivial to fix.
Andrew.