Thanks. We are exploiting an inter-procedural k-layer escape analysis, which are not dependent on inlining. So we will do some cross-procedure type propagation ourselves. :-) Could you give us some advices on it according to your experiences?
--clara ----- Original Message ----- From: "Mikhail Fursov" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 02, 2007 8:15 PM Subject: Re: [drlvm][jitrino]Are there any static type checking and type propagation? > My 2 cents: > > Clara, > in your example the type of collection is known at compile time (Tree) so no > devirtualization is required and 'virtual' call must be replaced with > 'special' (or direct) call by JIT. > If inliner inlines 'bodies' method - the type of 'bodyTab' is also known at > compile time and 'elements' method is also can be inlined. > > Right after method inlining you can see in log that there are operations > like 'copy o1(type MyMap), o2(type java.util.Map)' that are used to join > args and return values of inlinee and inliner methods. Use simplification > pass ('simplify','uce','dce') to remove redundant copy instructions and > propagate operand types. > > Hope it helps. > > On 02 Jul 2007 10:37:42 +0400, Egor Pasko <[EMAIL PROTECTED]> wrote: >> >> On the 0x307 day of Apache Harmony Xiao-Feng Li wrote: >> > On 7/2/07, clara <[EMAIL PROTECTED]> wrote: >> > > Each operand has type info in JIT IR, and I think the type is decided >> > > according to the declarations. >> > > However, the runtime type of some operands can be decided in >> compilation. >> > > Are there any optpasses which do some type inference or analyzing? >> > > >> > > For example, the below are 3 classes, according to analyzing the code, >> we >> > > know the runtime type of e is Body$Enumerate. >> > > >> > > public class BH >> > > { >> > > Tree root = new Tree(); >> > > ... >> > > public static final void main(String args[]) >> > > { >> > > for (Enumeration e = root.bodies(); e.hasMoreElements(); ) >> > > ... >> > > } >> > > } >> > > class Tree >> > > { >> > > ... >> > > private Body bodyTab; >> > > final Enumeration bodies() >> > > { >> > > return bodyTab.elements(); >> > > } >> > > ... >> > > >> > > } >> > > final class Body extends Node >> > > { >> > > final Enumeration elements() >> > > { >> > > // a local class that implements the enumerator >> > > class Enumerate implements Enumeration { >> > > private Body current; >> > > public Enumerate() { this.current = Body.this; } >> > > public boolean hasMoreElements() { return (current != >> null); } >> > > public Object nextElement() { >> > > Object retval = current; >> > > current = current.next; >> > > return retval; >> > > } >> > > } >> > > return new Enumerate(); >> > > } >> > > >> > > } >> > >> > Clara, now I understand what you meant. It is about cross-procedure >> > type propagation. I guess this should be done with IPA. I do not know >> > about how Jitrino deals with it. In Open64 (ORC) for speculative >> > analysis, we used inlining to propagate the information automatically. >> >> Yep, Jitrino loves to inline final methods. And here it would know the >> exact type. If there are several variants of a type on some call site, >> then the target type can be 'predicted' using profile information and >> then devirtualized (with a 'guard') upto the exact type. This >> optimization is limited and per-callsite. >> >> So, Jitrino does not perform inter-procedural type prediction >> optimization except one: the "Lazy Exception" optimization that allows >> to bypass constructing exception if it is not used in catch blocks of >> other methods. (In this case I would also prefer to aggressively >> inline the hottest throw-catch paths with partial inlining, to make >> code less bloated) >> >> >> -- >> Egor Pasko >> >> > > > -- > Mikhail Fursov >
