On the 0x269 day of Apache Harmony Mikhail Fursov wrote:
> Hi Rana,
>
> On 1/25/07, Rana Dasgupta <[EMAIL PROTECTED]> 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
