>>>>> "Paul" == Paul Biggar <[EMAIL PROTECTED]> 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