Re: java method calls and GIMPLE
Tom Tromey wrote: "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> But note that IPA via LTO is not going to permit callbacks into the Ian> front end, because there isn't going to be a front end. So the Ian> information needs to be represented in GIMPLE somewhere. Unfortunately there are lots of unsolved problems here, namely what the type system will look like. My current devirtualization pass relies on facts about the java type system in order to do its work. To make LTO work, we're going to want to understand what facts you need, and then get them passed on to LTO. If we can get a GIMPLE pass that can do what we need, then we're most of the way there. And unless I'm mistaken there are even simpler LTO problems that remain unsolved -- e.g., gcj sets flag_wrapv, but it seems to me that this would have to be a flag on operations rather than a global for LTO to be truly language independent. Sure, we've got to fix that. Want to help? :-) No question there's a long row to hoe, here. I would hope that we could start with a devirtualization pass on GIMPLE, using langhooks if necessary, and gradually migrate that to work with LTO. I certainly wouldn't argue that we should wait for LTO to be done to tackle devirtualization. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: java method calls and GIMPLE
On Wed, Oct 11, 2006 at 11:12:52AM -0600, Tom Tromey wrote: > > "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ian> But note that IPA via LTO is not going to permit callbacks into the > Ian> front end, because there isn't going to be a front end. So the > Ian> information needs to be represented in GIMPLE somewhere. > > Unfortunately there are lots of unsolved problems here, namely what > the type system will look like. My current devirtualization pass > relies on facts about the java type system in order to do its work. It seems that there should be commonalities that can be exploited; the rules for doing devirtualization in C++ are pretty close to those used for Java (though each language has relevant features the other lacks, like the Java "final" keyword).
Re: java method calls and GIMPLE
Andrew> Anyway, a front end callback is surely good enought for a proof of Andrew> concept. OBJ_TYPE_REF exists, is GIMPLE, and we already have a patch to add it to gcj. Tom
Re: java method calls and GIMPLE
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> But note that IPA via LTO is not going to permit callbacks into the Ian> front end, because there isn't going to be a front end. So the Ian> information needs to be represented in GIMPLE somewhere. Unfortunately there are lots of unsolved problems here, namely what the type system will look like. My current devirtualization pass relies on facts about the java type system in order to do its work. And unless I'm mistaken there are even simpler LTO problems that remain unsolved -- e.g., gcj sets flag_wrapv, but it seems to me that this would have to be a flag on operations rather than a global for LTO to be truly language independent. Tom
Re: java method calls and GIMPLE
Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Yes. You'll need to represent virtual function calls at the GIMPLE > > level, or to keep track of which calls are associated with which > > methods. This is key to getting IPA to work. > > > > It should be fairly easy, given a class and a vtable offset, to find > > the method. This will require a callback into the front end. > > But note that IPA via LTO is not going to permit callbacks into the > front end, because there isn't going to be a front end. So the > information needs to be represented in GIMPLE somewhere. I understand, but (IIRC) every time this has come up there has been some disagreement: I remember it being said that GIMPLE wasn't supposed to represent abstractions such as virtual methods. I may be misremembering! Anyway, a front end callback is surely good enought for a proof of concept. Andrew.
Re: java method calls and GIMPLE
Andrew Haley <[EMAIL PROTECTED]> writes: > Yes. You'll need to represent virtual function calls at the GIMPLE > level, or to keep track of which calls are associated with which > methods. This is key to getting IPA to work. > > It should be fairly easy, given a class and a vtable offset, to find > the method. This will require a callback into the front end. But note that IPA via LTO is not going to permit callbacks into the front end, because there isn't going to be a front end. So the information needs to be represented in GIMPLE somewhere. Ian
Re: java method calls and GIMPLE
> "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
Re: java method calls and GIMPLE
Paul Biggar writes: > I've come to a bit of an impasse in the (java) escape analysis. In > order to do interprocedural analysis effectively, I need to know what > methods are called. However, it is rarely the case that this > information is available. For example, a call to System.out.println > looks like this: > > out.0 = out; > out.1 = (struct *) out.0; > D.966 = out.1->vtable; > D.967 = D.966 + 124B; > D.968 = *D.967; > D.969 = (java.io.PrintStream:: *) D.968; > D.970 = _CD_HelloDate[1]; > D.971 = (struct *) D.970; > D.969 (out.0, D.971); > > So its all vtables, function lookups and indirect function calls. I > appreciate that that's how it works, but its not terribly useful to > me, and severely restricts what I can do. > > Ideally, I would have a list of methods that could be called at a > particular polymorphic function call. From there I can do whatever > analysis is appropriate. > > Any ideas how I'd go about this? Yes. You'll need to represent virtual function calls at the GIMPLE level, or to keep track of which calls are associated with which methods. This is key to getting IPA to work. It should be fairly easy, given a class and a vtable offset, to find the method. This will require a callback into the front end. Andrew.
