java method calls and GIMPLE

[Tom Tromey]

>>>>> "Paul" == Paul Biggar <paul.biggar@gmail.com> writes:

Paul> I've come to a bit of an impasse in the (java) escape analysis. In
Paul> order to do interprocedural analysis effectively, I need to know what
Paul> methods are called.

Paul> So its all vtables, function lookups and indirect function calls. I
Paul> appreciate that that's how it works, but its not terribly useful to
Paul> me, and severely restricts what I can do.

Paul> Ideally, I would have a list of methods that could be called at a
Paul> particular polymorphic function call. From there I can do whatever
Paul> analysis is appropriate.

Paul> Any ideas how I'd go about this?

You'll find it difficult to make a list of all methods that could be
called, because java allows runtime creation of new classes.  You
would have to assume that the world is closed -- which is pretty
unusual for (non-embedded) java code.

You probably know this already :)

Paul> PS it seems that even trivial examples, where the type is known at
Paul> compile time, generate code like this. Perhaps there's scope for a
Paul> polymorphism removal pass?

Yes, I have a java-specific devirtualization patch sitting here.  It
can devirtualize and also lower interface dispatch to virtual
dispatch.  This patch needs some work before it could go in.

You might be interested in the part of the patch that adds
OBJ_TYPE_REF wrappers to the generated trees.  This makes it much
simpler to go from a low-level CALL_EXPR (using offsets from the
vtable or whatnot) back to the decl for the called method.  See the
patch attached here:

    http://gcc.gnu.org/ml/java/2006-08/msg00020.html

The only reason I didn't commit the OBJ_TYPE_REF code yet is that I
wasn't sure that my choice for the OBJ_TYPE_REF_TOKEN value was the
best one.

Tom