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:20:03 GMT
On the 0x420 day of Apache Harmony George Timoshenko 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...

now I see the reason of your complains. Thanks, George. I have no
perfect plan in my mind yet. How do you like the idea to renumber
instructions thus making them not so suspicious? :)

BTW, we will see nothing suspicious after translator, then
suspiciousness will grow, but the growth is trackable and
controllable, thus making it not so suspicious :)

> 
> > please, elaborate more on how you see the HARMONY-5500. Especially this:
> > All HLO optimizations creates necessary instructions "manually". And
> > sometimes it is not very convenient.
> > what are examples of not very convenient? I suspect on-the-fly
> > optimization is not very convenient, but I might be wrong.
> 
> 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.

Okay, so, HARMONY-5500 is to unify the two IRBuilders. Nice. Good idea
too)) What is the time estimate for Kostya to do this? we should
consider it when deciding the scope of the work.

I like that Kostya is now aware of what IRBuilder does, how it
interacts with translator, simplifier and InstFactory. This is
important to know either way. So the time spent on this is not lost
anyway.

> 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.

now I see your point even better

-- 
Egor Pasko


Mime
View raw message