Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of mike.fursov@gmail.com
 designates 209.85.198.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=IwcYxUZYY7j+H0YaYCc6OAkco4JbpjpFxp4AbQ54kvzIMUumGfTSuR0FzXevTtJuvCMWvZSaq7KQz2AhdaeVyQb3dk6WfBznAn51TpVoMkGwPq/cffj8eqyUeCFAXNjGX0Ak3b9UXCSgnQLcSj0X0LFPRGiBCSjZGzYlxJrDFUA=
Message-ID: <bc79dd600803120118x5c19cad2ya31ee19679334d5d@mail.gmail.com>
Date: Wed, 12 Mar 2008 14:18:05 +0600
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][jitrino]Difference in bc-mapping after translator
In-Reply-To: <5b0732b20803120111u3d0349bek40b21743e8da73c1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2744_28215760.1205309885697"
References: <5b0732b20803111229j3a787d6di602436c3d2ec46aa@mail.gmail.com>
	 <bc79dd600803120107o4052e9a0p7c7bc9a7c9a52149@mail.gmail.com>
	 <5b0732b20803120111u3d0349bek40b21743e8da73c1@mail.gmail.com>

------=_Part_2744_28215760.1205309885697
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Looks like the reason is that LabelInst gets its offset in IRBuilder only
after next HIR inst is added to the block.
In this case we see that ILOAD_0 is not represented as HIR inst, so
LabelInst gets its offset from the second inst.
This is bug in translator.

The most simple fix is to move LabelInst bc-offset update from
Inst* IRBuilder::appendInst(Inst* inst) {
to
void IRBuilder::setBcOffset(uint32 bcOffset)

Anyway I think this problem is worth creating a JIRA issue.


On Wed, Mar 12, 2008 at 2:11 PM, Nikolay Kurtov <nkurtov@gmail.com> wrote:

> Here is the method's code
>
>    public static byte func(byte val) {
>        byte result = 1;
>        switch (val) {
>        case 0:
>            for (int i = 0; i < 54321; i++) {
>                result += i;
>            }
>            break;
>        case 1:
>            result = (byte) (val + 45);
>            break;
>        case 4:
>            result = (byte) (val + 21);
>            break;
>        default:
>            result--;
>            break;
>        }
>        if (result < 30) {
>            result <<= 1;
>        } else {
>            result /= 2;
>        }
>        return result;
>    }
>
> 2008/3/12, Mikhail Fursov <mike.fursov@gmail.com>:
> >
> > Nikolay, could you post a Java method here to reproduce the issue?
> >
> >
> > On Wed, Mar 12, 2008 at 1:29 AM, Nikolay Kurtov <nkurtov@gmail.com>
> wrote:
> >
> > > I compiled the same class with JET and OPT, and found a difference in
> > > bytecode-mapping
> > >
> > > One of branches of switch goes to this code:
> > > ;;  58) ILOAD_0
> > > ;;  59) BIPUSH          45
> > > ;;  61) IADD
> > > ;;  62) I2B
> > > ;;  63) ISTORE_1
> > > ....
> > > So, after the recompilation by OPT, the block should begin from
> bcOffset
> > > 58
> > >
> > > In OPT after translator I found in irdump the following block
> > > Block L5:
> > >  Predecessors: ENTRY_L0
> > >  Successors: L8
> > >  I5:L5: bcmap:59
> > >  I34:ldci4     #45 -) t14:int32
> > >  I35:add   t1, t14 -) t15:int32
> > >  I36:convi1  t15 -) t16:int32
> > >  I37:stvar     t16 -) v1:int32
> > > ....
> > >
> > > The block begins from bcOffset 59
> > > I consider these values in JET and OPT should be equal.
> > > Is it a bug?
> > >
> > > Now I'm exploring the code of JavaByteCodeTranslator and IRBuilder but
> > > cannot figure out the cause of problem
> > > Can you advise me how to fix it?
> > >
> > > --
> > > Regards,
> > > Nikolay
> > >
> > > mailto: nkurtov@gmail.com
> > >
> >
> >
> >
> >
> > --
> >
> > Mikhail Fursov
> >
>
>
>
> --
> Regards,
> Nikolay
>
> mailto: nkurtov@gmail.com
>


-- 
Mikhail Fursov

------=_Part_2744_28215760.1205309885697--