That's good, thanks Mikhail. And I agree about JET.
On 1/25/07, Mikhail Fursov <[EMAIL PROTECTED]> 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?
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
