harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naveen Neelakantam <neela...@uiuc.edu>
Subject Re: how to get the time used by the OPT, JET?
Date Sat, 27 Jan 2007 18:25:56 GMT

On Jan 27, 2007, at 6:25 AM, Egor Pasko wrote:

> On the 0x269 day of Apache Harmony Mikhail Fursov wrote:
>> Hi Rana,
>>
>> On 1/25/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>>>
>>> Hi,
>>> For the jit guys, I have a somewhat (?) related question.
>>> When looking at the jit logs for tight loops like:
>>>
>>> for( indx = 0; indx < 1000; indx++)
>>> {
>>>    afrom[indx] = afrom[indx + 1];
>>> }
>>>
>>> which is fairly common in Spec sequences, sorts, etc.....
>>> there are of course three checks during the assignmnet ...null  
>>> check, type
>>> check and bounds check. I wanted to make sure that for the above  
>>> pattern of
>>> code, the type check was being optimized away. Though is is more  
>>> potent in
>>> the jet compiler which I think calls a helper for this, I wanted to
>>> check this in the opt  compiler. I am quite new to jitrino's logs.
>>>
>>
>> I have 2 comments here:
>> 1) Let's avoid any optimizations in JET and leave it as simple as  
>> possilble.
>> Reasons: a) all hotstops are Jitrino.OPT targets b) Jitrino.JET is  
>> already ~
>> 10 times faster then SUN interpreter.
>>
>> 2) I tried the method:
>>     public static int foo6(String[] afrom) {
>>         for( int indx = 0; indx < 1000; indx++) {
>>             afrom[indx] = afrom[indx + 1];
>>         }
>>         return 0;
>>     }
>>
>> The complete IR is:
>> --------  irDump: Test::foo6  --------
>> Block ENTRY:
>>   Predecessors:
>>   Successors: L1
>>   I0:--- MethodEntry(Test::foo6): ()
>>   I4:defarg -) g1:cls:java/lang/String[]
>>   I6:ldci4     #0 -) g3:int32
>>   I7:stvar     g3 -) v1:int32
>>   GOTO L1
>>
>> Block L1:
>>   Predecessors: ENTRY L10
>>   Successors: L3 L2
>>   I1:L1:
>>   I8:ldvar     v1 -) t4:int32
>>   I9:ldci4     #1000 -) t5:int32
>>   I10:if cge.i4  t4, t5 goto L3
>>   GOTO L2
>>
>> Block L2:
>>   Predecessors: L1
>>   Successors: L8 UNWIND
>>   I2:L2:
>>   I11:ldci4     #1 -) t6:int32
>>   I12:add   t4, t6 -) t7:int32
>>   I13:chknull   g1 -) t8:tau
>>   GOTO L8
>>
>> Block L8:
>>   Predecessors: L2
>>   Successors: L9 UNWIND
>>   I34:L8:
>>   I14:tauhastype      g1,cls:java/lang/String[] -) t9:tau
>>   I15:arraylen  g1 ((t8,t9)) -) t10:int32
>>   I16:chkbounds t7 .lt. t10 -) t11:tau
>>   GOTO L9
>>
>> Block L9:
>>   Predecessors: L8
>>   Successors: L10 UNWIND
>>   I35:L9:
>>   I17:tauand       t9, t11 -) t12:tau
>>   I18:ldbase    g1 -) t13:ref:cls:java/lang/String
>>   I19:addindex  t13, t7 -) t14:ref:cls:java/lang/String
>>   I20:ldind.unc:str [t14] ((t8,t12)) -) t15:cls:java/lang/String
>>   I21:chkbounds t4 .lt. t10 -) t16:tau
>>   GOTO L10
>>
>> Block UNWIND:
>>   Predecessors: L2 L8 L9
>>   Successors: EXIT
>>   I32:L6:
>>   GOTO EXIT
>>
>> Block L10:
>>   Predecessors: L9
>>   Successors: L1
>>   I36:L10:
>>   I22:tauand       t9, t16 -) t17:tau
>>   I23:tauexacttype      g1,cls:java/lang/String[] -) t18:tau
>>   I24:addindex  t13, t4 -) t19:ref:cls:java/lang/String
>>   I25:stind.unc:str t15 ((t8,t17,t18)) -) [t19]
>>   I26:stvar     t7 -) v1:int32
>>   GOTO L1
>>
>> Block L3:
>>   Predecessors: L1
>>   Successors: RETURN
>>   I3:L3:
>>   I29:return    g3
>>
>> Block RETURN:
>>   Predecessors: L3
>>   Successors: EXIT
>>   I31:L5:
>>   GOTO EXIT
>>
>> Block EXIT:
>>   Predecessors: RETURN UNWIND
>>   Successors:
>>   I33:L7:
>>
>> Loop exits are:
>> 1)   I10:if cge.i4  t4, t5 goto L3 -> bounds check->OK (a  
>> candidate for
>> unroll optimization I'm finishing now)
>> 2)   I13:chknull   g1 -) t8:tau -> checks that array is not NULL. The
>> optimization to move this check out of the loop is loop peeling  
>> and it is
>> enabled only in server mode today. However if NullPointerException  
>> is not
>> caught in the same method, Jitrino.OPT does not generate null- 
>> checks and
>> hardware exception filter is used here.
>> 3)   I16:chkbounds t7 .lt. t10 -) t11:tau and
>> 4)   I21:chkbounds t4 .lt. t10 -) t16:tau are bounds checks for  
>> [i], [i+1]
>> elements. I think it's ok too. We need these checks because loop  
>> limit is
>> not arr.length but some number. May be abcd can help us here?
>
> Unfortunately, not. Pure ABCD does not solve this bound check. We need
> a proper "loop versioning" for ABCD to solve it. TBD.

I believe ABCD would remove (4), the check for afrom[i].  It is  
dominated by (3), the check for afrom[i +1].

And if the loop is peeled or unrolled, I believe all but the first  
bounds check would be eliminated.

We need Egor's reimplementation ABCD thought to try this out.  I  
think I've finished it, but have not contributed the changes back yet.

>
>> The taus like
>>   I14:tauhastype      g1,cls:java/lang/String[] -) t9:tau
>> and
>>   I23:tauexacttype      g1,cls:java/lang/String[] -) t18:tau
>> are assertions(statements) in Jitrino.OPT. No checking code is  
>> generated and
>> these tau can be used as 'true' or 'check was done' flag in a code it
>> dominates.
>>
>> But looking at L8, L9, L10, I am not sure that I understand that  
>> the type
>>> check is going away, or what is happening to tauhastype.
>>>
>>
>> It's easy to understand with taus if 'tau' is a simple statement  
>> or a helper
>> call. If tau-op finishes the block and you see exception edge ->  
>> Jitrino's
>> optimizer treats it like a helper call (but the call still can be  
>> eliminated
>> in CG!). If tau does not ends a block -> this is a statement and  
>> there will
>> no code generated for it.
>>
>> Is there a manual on the tau operators that the non jitrino people  
>> can read
>>> ?
>>>
>>
>> I've never seen this manual. I've learned taus from the code and  
>> IR by
>> myself. But I'm going to ask this question and will send a reply  
>> if the
>> manual exists :)
>>
>> -- 
>> Mikhail Fursov
>
> -- 
> Egor Pasko
>


Mime
View raw message