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: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Tue, 08 Apr 2008 20:11:15 GMT
On the 0x420 day of Apache Harmony Alexei Fedotov wrote:
> > physicist
> AFAIK, NSU graduates in physics become incomparable programmers.

I am a mathematician, do not start a holywar here :)

> On Tue, Apr 8, 2008 at 1:36 PM, Okonechnikov Konstantin
> <okko73313@gmail.com> wrote:
> > On 4/8/08, George Timoshenko <george.timoshenko@gmail.com> wrote:
> >  >
> >  > Egor Pasko wrote:
> >  >
> >  > But what is the reason not to?
> >  > >
> >  >
> >  > The main value of simplifying-on-the-fly in my opinion is reducing the
> >  > number of generated instructions. Of course, they will be eliminated later
> >  > by separate "simplify", but then you get gaps in instruction ids.
> >  >
> >  > Basing on quite long debugging experience I can say it is a problem when
> >  > you see a lot of instruction sets with non-continuous ids. Such region looks
> >  > suspicious: the instructions were created by different passes, and you have
> >  > to ensure their order and effects are correct. "simplifying-on-the-fly"
> >  > allows to reduce the number of such regions.
> >  >
> >  > The situation reminds me the joke when physicist and mathematician boil
> >  > water on the camp-fire. Removing simplifier and CSE from IRBuilder is a
> >  > mathematician's approach for me.
> >  >
> >  > From another side I understand that from the design point of view The idea
> >  > of IRBuilder cleanup makes translation phase more clear for new participants
> >  > of Jitrino development.
> >  > I can not agree this makes translator easier to debug: just switch OFF the
> >  > flags and you get pure IRBuilder...
> >
> >
> >  Good arguments. I should take them into account.
> >  And as a physicist maybe I have to :)
> >  So, the problem is not exatly with the IrBuilder itself. Well, at least,
> >  It is OK to use it in new translator implementation.
> >
> >
> >
> >  > The main example of IRBuilder availability is HLOAPIMagic pass.
> >  > It is needed there to manage InstructionFactory, a number of nodes for
> >  > generating instructions and labels for them...
> >  > The part of IRBuilder is just copy/pasted there - that is what I want to
> >  > get rid of.
> >  > I agree this is difficult to imagine an HLO pass which needs
> >  > simplification on the fly. But I insist it is needed at the translation.
> >
> >
> >  Pehaps working on replacing HLOAPIMagicIRBuilder in HLOAPIMagic with
> >  IrBuilder or its derived class will
> >  help me to get even better understanding on how IrBuilder works (IMO I got
> >  familiar with it while I was "cleaning it up"). But of course, I will
> >  require community help & support. Also it's not clear for me yet how
> >  much time will it take me to manage this task, if I am assigned to it.
> >  And I am not quite sure if this task is in the scope of the translator
> >  project.
> >
> 
> 
> 
> -- 
> With best regards,
> Alexei
> 

-- 
Egor Pasko


Mime
View raw message