harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Sidelnikov <nikolay.sidelni...@gmail.com>
Subject Re: [drlvm][jit][opt] HARMONY-3243 It's possible to fill array with constant much faster
Date Fri, 16 Mar 2007 09:48:21 GMT
>> What I can say more is that a good "ABCD" optimization complimented
> ... and ABCD does nothing with BBP, isn't it?
> 
>> with "loop versioning" optimiztion will make a more readable, more
>> stable code, AND will give a better performance gain (loop unrolling
> Unfortunately no, it will not. :-(
> 
> As you probably know ;-), char is 16 bits wide in Java.
> The code generated for char moves have to use 16 bit movement
> instructions. These instructions include operand-size change prefix
> (66h) that makes CPU decoder feel bad. Whatever unrolling or versioning
> would leave these heavy instructions on place.
> One of the goals was to throw the heavy instructions away and replace
> them with more effective and fast ones. It's somehow hard to do in
> codegen separately, but much easy (and clearly) with a little help from
> the HLO side - this is rationale for the HLO pass.
> 
>> is awake too). Setting aside the fact that the overall design will be
>> more straightforward (having no interdependent passes, extra helpers, 
>> etc)
>>
>> So I vote for focusing on ABCD plus "loop versioning" and leaving 
>> specific benchmark-oriented tricks (complicating our design) alone.
> 
> Again, the optimization is orthogonal to the ABCD and was never
> positioned as replacement for ABCD. Optimization's main target are
> string (and XML) intensive apps.
> 
My 2 cents:

I hope we will use results of the ABCD optimization to completely 
replace regular loop with a helper call


Mime
View raw message