You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nikolay Kurtov <nk...@gmail.com> on 2008/03/11 20:29:47 UTC
[drlvm][jitrino]Difference in bc-mapping after translator
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
Re: [drlvm][jitrino]Difference in bc-mapping after translator
Posted by Nikolay Kurtov <nk...@gmail.com>.
Yes, it fixes the problem
2008/3/12, Mikhail Fursov <mi...@gmail.com>:
>
> Please check the patch if it fixes the problem
>
>
> On Wed, Mar 12, 2008 at 3:18 PM, Nikolay Kurtov <nk...@gmail.com> wrote:
>
> > JIRA issue created
> > https://issues.apache.org/jira/browse/HARMONY-5595
> >
> > 2008/3/12, Mikhail Fursov <mi...@gmail.com>:
> > >
> > > 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 <nk...@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 <mi...@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
> > >
> >
> >
> >
> > --
> > Regards,
> > Nikolay
> >
> > mailto: nkurtov@gmail.com
> >
>
>
>
>
> --
>
> Mikhail Fursov
>
--
Regards,
Nikolay
mailto: nkurtov@gmail.com
Re: [drlvm][jitrino]Difference in bc-mapping after translator
Posted by Mikhail Fursov <mi...@gmail.com>.
Please check the patch if it fixes the problem
On Wed, Mar 12, 2008 at 3:18 PM, Nikolay Kurtov <nk...@gmail.com> wrote:
> JIRA issue created
> https://issues.apache.org/jira/browse/HARMONY-5595
>
> 2008/3/12, Mikhail Fursov <mi...@gmail.com>:
> >
> > 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 <nk...@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 <mi...@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 <nk...@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
> >
>
>
>
> --
> Regards,
> Nikolay
>
> mailto: nkurtov@gmail.com
>
--
Mikhail Fursov
Re: [drlvm][jitrino]Difference in bc-mapping after translator
Posted by Nikolay Kurtov <nk...@gmail.com>.
JIRA issue created
https://issues.apache.org/jira/browse/HARMONY-5595
2008/3/12, Mikhail Fursov <mi...@gmail.com>:
>
> 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 <nk...@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 <mi...@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 <nk...@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
>
--
Regards,
Nikolay
mailto: nkurtov@gmail.com
Re: [drlvm][jitrino]Difference in bc-mapping after translator
Posted by Mikhail Fursov <mi...@gmail.com>.
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 <nk...@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 <mi...@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 <nk...@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
Re: [drlvm][jitrino]Difference in bc-mapping after translator
Posted by Nikolay Kurtov <nk...@gmail.com>.
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 <mi...@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 <nk...@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
Re: [drlvm][jitrino]Difference in bc-mapping after translator
Posted by Mikhail Fursov <mi...@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 <nk...@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