harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: how to get the time used by the OPT, JET?
Date Thu, 25 Jan 2007 18:23:37 GMT
That's good, thanks Mikhail. And I agree about JET.

On 1/25/07, Mikhail Fursov <mike.fursov@gmail.com> 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?
>
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message