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 Mon, 07 Apr 2008 06:32:34 GMT
On the 0x41F day of Apache Harmony George Timoshenko wrote:
> Okonechnikov Konstantin wrote:
> 
> > I have some good news: Simplifier and CSE removal from IRBuilder is
> > accomplished.
> > 1) What is done:
> > - Simplifier* IrBuilder::simplifier and all connected methods are removed or
> > modified
> > - CSEHashtable IrBuilder::cseHashTable and its methods are removed
> > - Instruction generation doesn't include simplification and hashing anymore
> > - DoSimplify, DoCSE flags are removed from IRBuilderFlags
> 
> That's awful. I see the discussion too late.
> 
> This is much easier to destroy rather than to improve.
> Does irBuilder simplify/hvn ability prevents you from writing new
> translator?

no, it does not prevent. Kostya started from this task to better
understand what translator does and improve the output side of
translator.

> I am strongly against the idea of removing simplify/hvn from IRBuilder.
> 
> 
> In HARMONY-5500 there is NOTHING about this removing.

yep, nothing. But what is the reason not to? I see only one: faster
translator on systems without JET. This is not a good reason, IMHO.

I remember Mikhail Fursov complaining about optimizing nature of
translator that makes it harder to debug bytecode -> IR mapping.

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.




-- 
Egor Pasko


Mime
View raw message