This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Gimplifying Java
- From: Andrew Haley <aph at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: java at gcc dot gnu dot org, <gcc at gcc dot gnu dot org>
- Date: Tue, 17 Jun 2003 19:29:36 +0100
- Subject: Re: [tree-ssa] Gimplifying Java
- References: <bcmap6$h4t$1@main.gmane.org><Pine.LNX.4.44.0306170853180.28733-100000@ops2.one-point.com>
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.