Egor Pasko said the following on 17.01.2008 15:41:
On the 0x3CE day of Apache Harmony Simon Chow wrote:
On 17 Jan 2008 13:31:05 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote:
On the 0x3CE day of Apache Harmony Simon Chow wrote:
On 17 Jan 2008 11:08:54 +0300, Egor Pasko <[EMAIL PROTECTED]> 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? :)
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?
It runs in interpreter mode ATM. On JIT there is something bad
happening, a classloader helper is called with a class handle NULL and
fails on assertion that it shouldn't be NULL. How this NULL handle was
passed to the helper I don't know because I didn't debug compiled code.
DRLVM compiles on old SLES9 gcc 3.3.3 but fails to compile on SLES10 gcc
4.1.2. The reason is several assembly files which new assembler doesn't
like (some compiler directives have to be removed) and a couple of C++
errors coming from Jitrino code. I didn't fix assembly yet because I
can't test whether the result would actually work since I can't get to
the end of DRLVM build.
--
Gregory
