Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 64123 invoked from network); 17 Jan 2008 14:26:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Jan 2008 14:26:45 -0000 Received: (qmail 57431 invoked by uid 500); 17 Jan 2008 14:26:33 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 57402 invoked by uid 500); 17 Jan 2008 14:26:33 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 57393 invoked by uid 99); 17 Jan 2008 14:26:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jan 2008 06:26:33 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of simon.harmony@gmail.com designates 64.233.162.235 as permitted sender) Received: from [64.233.162.235] (HELO nz-out-0506.google.com) (64.233.162.235) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jan 2008 14:26:06 +0000 Received: by nz-out-0506.google.com with SMTP id o37so536610nzf.0 for ; Thu, 17 Jan 2008 06:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=D6PNYHDGOevAskC+y6WB7YcVdspGR51hZ8cZLSRDsU4=; b=tWjMA+SGpzrli8w70eoWJne4KVHFO9ej7LeHUi/Op1SHTu1xJDleJVd6cE1786Q/LHBoDR4ZaNvR/rXEgv5I4YcSBGU0f17xChQ5S8lcEtzGTJUvpjjrDmJZGELFgO7ieLWjrT5RUbGSRdwuGGI4bc7hM//3sw0bgEgDfRayR00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=yEpKxU+/xvaYbeKTQfASFULS1GJ6V91QV9niiOS2LMmMYw1lQ899UesC9bw4JpNoPjFkvIqnDhplZv2HAkSabH3lrEWskBRL9nsBEzFRRb3A5YNlzQ2zg5LGDdP9vfpOh2USah4sadTBy7WLESrPwLWsCIcQvUjKXON4lGEnXnE= Received: by 10.114.109.1 with SMTP id h1mr2483287wac.45.1200579971189; Thu, 17 Jan 2008 06:26:11 -0800 (PST) Received: by 10.114.81.7 with HTTP; Thu, 17 Jan 2008 06:26:11 -0800 (PST) Message-ID: <3db9f87f0801170626j2824e91co21709f2027ba7e6d@mail.gmail.com> Date: Thu, 17 Jan 2008 22:26:11 +0800 From: "Simon Chow" To: dev@harmony.apache.org Subject: Re: [drlvm][opt][translator] What dose JavaLabelPrepass do? In-Reply-To: <0vqbq7klj4r.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_37019_5161053.1200579971171" References: <3db9f87f0801160524t116f4e6dv9a6e5e9e87d81bb@mail.gmail.com> <0vqk5m8lvqh.fsf@gmail.com> <3db9f87f0801170104x6282a0ffi7e8595ad5533e61c@mail.gmail.com> <0vqfxwwlp5i.fsf@gmail.com> <3db9f87f0801170259p2356b621va2506d315b0f7793@mail.gmail.com> <0vqbq7klj4r.fsf@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_37019_5161053.1200579971171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 wrote: > > On the 0x3CE day of Apache Harmony Simon Chow wrote: > > On 17 Jan 2008 13:31:05 +0300, Egor Pasko wrote: > > > > > > On the 0x3CE day of Apache Harmony Simon Chow wrote: > > > > On 17 Jan 2008 11:08:54 +0300, Egor Pasko > 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 ------=_Part_37019_5161053.1200579971171--