harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Tue, 08 Apr 2008 12:00:09 GMT
> physicist
AFAIK, NSU graduates in physics become incomparable programmers.

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

Mime
View raw message