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: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: how to get the time used by the OPT, JET?
Date: 27 Jan 2007 18:25:47 +0600
Lines: 165
Message-ID: <uzm848xmc.fsf@gmail.com>
References: <6342af3e0701161847i373474d8g42d5f744002de0e5@mail.gmail.com>
 <f944d83d0701162130h499be2cq3af3df3aa31acd16@mail.gmail.com>
 <6342af3e0701170034q681b8a41t8f91343bb2e3b69a@mail.gmail.com>
 <bc79dd600701170226q17f2dd6x41cc2496ec770979@mail.gmail.com>
 <6342af3e0701171728s70d85c51s9b37a0fb127621f@mail.gmail.com>
 <bc79dd600701172323i1cc09532o494675296538137e@mail.gmail.com>
 <51d555c70701242220v7ae85a6blf5b4d1fdcb2d791b@mail.gmail.com>
 <bc79dd600701250059q463c958dsa9989fb1f6a492e0@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

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.

> 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