Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Nikolay Sidelnikov <nikolay.sidelnikov@gmail.com>
Subject: Re: [drlvm][jit][opt] HARMONY-3243 It's possible to fill array with
   constant much faster
Date: Fri, 16 Mar 2007 15:48:21 +0600
Lines: 32
Message-ID: <etdp56$re8$1@sea.gmane.org>
References: <0vqhcsmo33l.fsf@gmail.com> <etd8hh$fqu$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
In-Reply-To: <etd8hh$fqu$1@sea.gmane.org>
Sender: news <news@sea.gmane.org>

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