21 Mar 2008 12:00:22 +0300, Egor Pasko <[EMAIL PROTECTED]>: > On the 0x40D day of Apache Harmony Okonechnikov Konstantin wrote: > > >hm, and how is it going? :) > > > > well, right now I modify [codegen]->stacklayout action. Callee-save > > registers are always being saved/restored in the begining/end of the > > method. But sometimes not all pathes use callee saved regs. > > Motion of the spill code inside CFG can reduce memory calling rate. > > (So called "shrink wrapping" > > technique). I have > > already implemented functions that collect info about callee save regs > > usage in each block and find proper postion for spill code, > > hope to finish the optimization to the end of April. > > wow, this is a very interesting work, assuming some tradeoffs to > consider. I love this :) > > > >seriously, what is your experience with the code? > > > > I am familiar with common principles ( DRVLM,HIR, LIR, CFG etc) > > and have expierience with codegenerator. > > nice nice nice > > > > ... there is a JavaLabelPrepass class that namely should only mark > > >boundaries of basic blocks. But it does a lot more, for example, > > >inferring types of variables. It is very complicated, makes > > >unpredictable number of traversals through the bytecode, not easy to > > >support. > > > > Some questions. > > As I > > understood TranslatatorSession::translate() starts parsing calling > > JavaTranslator::translateMethod(), right? > > Then we parse bytecode using JavaByteCodeTranslator as parser > > callback. When are JavaLabelPrepass methods called? > > I agree, this is not very logical. You are now closer to the crappy > code, just start feeling it :) > > in constructor of JavaByteCodeTranslator: > JavaByteCodeTranslator.cpp:142: initLocalVars(); > > in initLocalVars:220: > // > // perform label prepass in this method > // > parser.parse(&prepass); > prepass.parseDone(); > > it was supposed that parser incapsulates generic code for parsing, > but it does not have a lot of code to incapsulate and only makes things > more complicated. > > > What is VariableIncarnation? What is SlotVar? > > In brief, VariableIncarnation will refer to a single operand in > HIR. But during translation phase we do not know which variables > (local variables and stack variables) will represent the same operand, > so, during translation VariableIncarnations will be connected in > chains of equivalent vars. One chain represent a future operand. > > SlotVar .. you know, slot is an element of java operand stack. Just to > keep corresponding VariableIncarnations connected to the slot in > operation. > > Details later, if you wish. IMO the JavaLabelPrepass quite closely implements data-flow analysis as described in JVMS [1], and VariableIncarnations represent merged state of variables for each instruction, as Egor said. [1] http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9801
> I think you should not dive into details of JavaLabelPrepass. Better > try avoid it. And implement a readable and nice translator from scratch. > > > > ...IRBuilder separation necessity is reported as HARMONY-5500. > > Looks like refactoring of JavaLabelPrepass and IRBuilder separation are > > quite independent tasks. And separation is more important, isn't it? > > JavaLabelPrepass has nothing in common with IRBuilder. Though, both > are a part of the translator. I cannot judge the importance here. Both > improve design, readability, etc. IRBuilder separation is easier to > implement, and, probably, this is what you want to start from. > > > >A good example of clean code that does similar things is Jitrino.JET > > >compiler, but I did not investigate if it could be reused. Maybe you > > >can first try to build IR by extending Jitrino.JET. > > You mean modify or extend > > JET in order to use instead of JavaByteCodeTranslator? > > I meant take the basic concept and implement translator using this > concept/code-patterns. Then decide if there is a common part between > two and whether we need to separate it. > > I suggest to look more in JET code than in prepass or translator when > implementing the next big thing :) JFYI, I recall there are peculiarities related to subroutines (JSRs) processing, and current JET does not handle them completely (HARMONY-4740). So you might want to fix that as well ;) -- Alexey Varlamov > > -- > Egor Pasko > >
