Re: how to get the time used by the OPT, JET?

[Naveen Neelakantam]

On Jan 27, 2007, at 6:25 AM, Egor Pasko wrote:
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.

I believe ABCD would remove (4), the check for afrom[i].  It is  
dominated by (3), the check for afrom[i +1].

And if the loop is peeled or unrolled, I believe all but the first  
bounds check would be eliminated.

We need Egor's reimplementation ABCD thought to try this out.  I  
think I've finished it, but have not contributed the changes back yet.


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