harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][opt][translator] What dose JavaLabelPrepass do?
Date Thu, 17 Jan 2008 14:33:32 GMT
On the 0x3CE day of Apache Harmony Xiao-Feng Li wrote:
> On 17 Jan 2008 15:41:08 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > On the 0x3CE day of Apache Harmony Simon Chow wrote:
> > > On 17 Jan 2008 13:31:05 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> > > >
> > > > On the 0x3CE day of Apache Harmony Simon Chow wrote:
> > > > > On 17 Jan 2008 11:08:54 +0300, Egor Pasko <egor.pasko@gmail.com>
wrote:
> > > > > >
> > > > > > On the 0x3CD day of Apache Harmony Simon Chow wrote:
> > > > > > > I am studying OPT in jitrino. For understanding the process
of
> > > > building
> > > > > > CFG,
> > > > > > > I have read some code of JavaByteCodeTranslator.
> > > > > > > In the constructor of JavaByteCodeTranslator, there is
an additional
> > > > > > pass
> > > > > > > named JavaLabelPrepass,
> > > > > > > I would like to ask what is the exact purpose of this pass?
> > > > > >
> > > > > > the purpose is to mark basic blocks and inference stack variables
and
> > > > > > local variables with their types.
> > > > > >
> > > > > > This information goes to the input of JavaByteCodeTranslator,
which in
> > > > > > single pass goes through each bytecode instruction and converts
it to
> > > > > > operand-based representation from the stack-based in bytecode.
> > > > > >
> > > > > > The problem is a little tricky (with variable merging logic)
and
> > > > > > current design is poor.
> > > > > >
> > > > > > > Besides this, It is seems that the translator part will
be refined,
> > > > > > which I
> > > > > > > saw in the wiki. Has it already been done in the current
version?
> > > > > > > Thanks!
> > > > > >
> > > > > > no, translator is not refined, low priority task.
> > > > > >
> > > > > > Why do you study the process of building CFG? If you want to
do
> > > > > > something with it, I would suggest to try some other place since
all
> > > > > > JIT people here will agree that debugging JavalabelPrepass is
> > > > > > brain-damaging.
> > > > >
> > > > >
> > > > > Thank!
> > > > > I am doing a project for combining static compiler with dynamic
> > > > compilation
> > > > > environment (jitrino.OPT)
> > > > > As first step, now I am planning to translate the Harmony IR to WHIRL.
> > > >
> > > > hm, do you have a kind of draft design document on how you want to do
> > > > this? ..probably Harmony gurus can give some valuable input having
> > > > read this doc.
> > >
> > >
> > > There is no document for this yet, but I will write one in the next few days
> > > after having a discussion with others in my group.
> > > Our static compilation platform is Open64, some of my teammates are working
> > > on it.
> >
> > just to make sure.. is the primary goal to replace/enhance Jitrino.OPT
> > on IPF machines? Oh, those itanics..
> >
> > > I only have a little understanding of jitrino.OPT.
> > > For achieving higher performance, which part or phases of jitrino.OPT could
> > > be refined or replaced by Open64 optimization?
> > > Could you give me some suggestion?
> >
> > I am afraid I am not familiar with Open64 at all, and there are
> > concerns using a mix of Jitrino.OPT and Open64 since the latter is
> > licensed under GPL. So, do not show me their code :)
> >
> > Jitrino.OPT/IPF is rather immature/experimental/untested/etc. So, if
> > using Jitrino.OPT on IPF consider throwing away the code generator
> > (but take care about generating the right calling convention and
> > VM-related stuff like threading)
> >
> > As for the High-level optimizations, I do not know, where Open64 is
> > better, maybe Xiaofeng knows? :)
> 
> As I know, the team led by Prof Yang and Mao are using Open64 with the
> new X86 backend. :) Of course,
> if they make it well, they can apply the work to IPF as well.
> I think the major issues are in root set enumeration support and the
> stack frame work (gc safepoint, exception). Open64 middle-end has been
> designed and tuned very well. But the issue is how to expand the
> optimization scope with IPA, such as virtual method inlining and
> escape analysis, etc.

yes, I agree, all these problems need to be resolved. It is a lot of
work. But the benefit of throwing profile away here and there is, hm,
very doubtful, right? :)

-- 
Egor Pasko


Mime
View raw message