harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Chow" <simon.harm...@gmail.com>
Subject Re: [drlvm][opt][translator] What dose JavaLabelPrepass do?
Date Thu, 17 Jan 2008 14:26:11 GMT
Actually, we are targeting at x86 platform :)  IPF is not concerned until
now.
I am sorry that I did not make this clear before.
Now we just plan to enhance OPT using Open64 only for loops and other
computation-intensive sections.
Does it have some opportunities for performance improving?
As you said, code motion and prefetch optimizations is more helpful in C
compilers,
and what is the advantaging we can take using JIT compiler? profiling? and?
I have little experience here.

And I have not tried DRLVM on IPF yet...

Thanks

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.OPTcould
> > 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? :)
>
> I may try to forsee something: Fortran & C compilers have more freedom
> for code motion and prefetch optimizations than a Java JIT compiler
> (which has a more dynamic nature), so, when ported to Java realities a
> C compiler is likely to behave not very cool.
>
> I would suggest you to enhance Jitrino IPF codegenerator in
> if-conversion and register allocation, that looks like more
> interesting and performance-beneficial. However, I am not sure if it
> suits you good as a subject of research.
>
> Did you try running DRLVM on IPF? Does it work? Does it even compile?
>
> > By the way, This idea is original from Xiaofeng :)
> >
> > Thank you every much!
> >
> > > But I can not find more information for the CFG structure in
> jitrino.OPT,
> > > > which leads me to read the code in translation part. :(
> > > > Any advice for this?
> > >
> > > there is no complete reference guide for HIR instructions yet. Once I
> > > gave advice on this:
> > >
> > > http://article.gmane.org/gmane.comp.java.harmony.devel/24474/
> > >
> > > feel free to ask specific questions on CFG and instructions :)
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
> >
> > --
> > From : Simon.Chow@Software School of Fudan University
>
> --
> Egor Pasko
>
>


-- 
>From : Simon.Chow@Software School of Fudan University

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message