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.
In the debugger, I see that the jitrino.opt compilation does
genTauCheckElementType() which finally simplifies through
simplifytaucheckelementtype(). This does a subclass check and for the above
generates a genTauHasExactType...
In the log ( attached ) , in the HIR, after global operand analysis, the ct
log shows:
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
I33:L8:
I14:tauhastype g1,cls:ArrayRef[] -) 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
I34:L9:
I17:tauand t9, t11 -) t12:tau
I18:ldbase g1 -) t13:ref:cls:ArrayRef
I19:addindex t13, t7 -) t14:ref:cls:ArrayRef
I20:ldind.unc:o [t14] ((t8,t12)) -) t15:cls:ArrayRef
I21:chkbounds t4 .lt. t10 -) t16:tau
GOTO L10
Block UNWIND:
Predecessors: L2 L8 L9
Successors: EXIT
I31:L6:
GOTO EXIT
Block L10:
Predecessors: L9
Successors: L1
I35:L10:
I22:tauand t9, t16 -) t17:tau
I23:tausafe() -) t18:tau
I24:addindex t13, t4 -) t19:ref:cls:ArrayRef
I25:stind.unc:o t15 ((t8,t17,t18)) -) [t19]
I26:stvar t7 -) v1:int32
GOTO L1
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. Is there a manual
on the tau operators that the non jitrino people can read ? I think the
final code generated is fine since the only exception being checked in the
generated code is the bounds check. Sorry for the long question.
Rana
On 1/18/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Answers:
On 1/18/07, zouqiong <[EMAIL PROTECTED]> wrote:
>
> Thanks. I want to know about three things:
>
> 1) the compilation time for both OPT and JET.
-XDjit.arg.time=on
If you need to measure total time for your code/algorithm add new timer.
See
any of existing timers (search by it's name in log) to see how it's work.
2) IR and compilation log for a method compiled by OPT.
All IR:
-Xem:opt -XDjit.arg.log=ct,irdump,dotdump
IR for the specified method:
-Xem:opt -XDjit.CS_OPT.f.filter=Test::main -XDjit.f.arg.log=ct
,irdump,dotdump
Read this doc to learn more:
http://harmony.apache.org/subcomponents/drlvm/JIT_PMF.html
3) some runtime metrics for managed code.
-Xem:opt -XDjit.arg.codegen.iprof=on -
XDjit.arg.codegen.iprof.config=iprof.cfg
Note! you can use per-method filters here too.
Read this doc to learn more:
http://harmony.apache.org/subcomponents/drlvm/internal_profiler.html
--
Mikhail Fursov
