You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by xiaoming gu <xi...@gmail.com> on 2008/07/10 11:36:58 UTC
a quick question for signed shift right for long type
Hi, all. I just got a problem with signed shift right problem.
long a = 0x8000000000000000;
long b = a>>63; // b is 0xffffffffffffffff
But if I use SAR to do the signed shift right in harmony internally, b is
0xffffffff00000001.
I traced the code for a while and couldn't find the difference for the two
ways.
Any idea? Thanks.
Xiaoming
Re: a quick question for signed shift right for long type
Posted by xiaoming gu <xi...@gmail.com>.
Without optimizing I8 case, the ArrayIndexOutOfBoundsException still exists
in nbody_long and
spectralnorm_long. It looks like there are two bugs - one with NumberFormat
and the other with
I8. I'm going to investigate the first case tomorrow. Thanks.
Xiaoming
On Thu, Jul 10, 2008 at 9:14 PM, Aleksey Shipilev <
aleksey.shipilev@gmail.com> wrote:
> Xiaoming,
>
> Well, it looks like I get it.
>
> You're trying to optimize I8 multiplication, which is not directly
> supported on ia32. The original code generates I8PseudoInst for this
> multiplication and then lowers it in Ia32I8Lowerer.cpp. But you can
> operate on I4 only, so you must drop out one of the branches in your
> patch. Shame on me, I read the patch inattentively...
>
> I haven't idea what to do with I8Lowerer, looks like we need to handle
> 2^k multiplications and divisions there too. Let's handle I4 in
> InstCodeSelector for now, then open a new JIRA for long operations. We
> can back there some day.
>
> Thanks,
> Aleksey.
>
> On Thu, Jul 10, 2008 at 5:04 PM, Aleksey Shipilev
> <al...@gmail.com> wrote:
> > Xiaoming, a couple of questions:
> > 1. Is this a reason for ICU-related failure?
> > 2. Does it reproduce in Java code for you?
> >
> > I had written the test [1] and run it with HARMONY-5901 onboard:
> > $ ../builds/shade.5901/bin/java -Xem:opt testShift
> > a = -70
> > b = -1
> >
> > -Xem:opt used to make sure the method is compiled with OPT.
> > I can't see the failure you mention... Can you describe the steps to
> reproduce?
> >
> > Thanks,
> > Aleksey.
> >
> > [1]
> > public class testShift {
> >
> > public static void main(String[] args) {
> > long a = -70;
> > long b = a >> 63;
> >
> > System.out.println("a = " + a);
> > System.out.println("b = " + b);
> > }
> >
> > }
> >
> > On Thu, Jul 10, 2008 at 4:45 PM, xiaoming gu <xi...@gmail.com>
> wrote:
> >> With H5901-V2.patch, A/16=-5 if A=-70 and A is a long. After checking
> each
> >> step, I found the mask
> >> for a>>63 is not right, which should be 0xffffffffffffffff but is
> >> 0xffffffff00000001. I tried many ways but couldn't
> >> find the reason. Thanks for your help.
> >>
> >> Xiaoming
> >>
> >> On Thu, Jul 10, 2008 at 5:53 PM, Aleksey Shipilev <
> >> aleksey.shipilev@gmail.com> wrote:
> >>
> >>> Hi, Xiaoming!
> >>>
> >>> Can you provide the exact test case?
> >>> It's not obvious what do you try to say.
> >>>
> >>> Thanks,
> >>> Aleksey.
> >>>
> >>> On Thu, Jul 10, 2008 at 1:36 PM, xiaoming gu <xi...@gmail.com>
> >>> wrote:
> >>> > Hi, all. I just got a problem with signed shift right problem.
> >>> >
> >>> > long a = 0x8000000000000000;
> >>> > long b = a>>63; // b is 0xffffffffffffffff
> >>> >
> >>> > But if I use SAR to do the signed shift right in harmony internally,
> b is
> >>> > 0xffffffff00000001.
> >>> > I traced the code for a while and couldn't find the difference for
> the
> >>> two
> >>> > ways.
> >>> >
> >>> > Any idea? Thanks.
> >>> >
> >>> > Xiaoming
> >>> >
> >>>
> >>
> >
>
Re: a quick question for signed shift right for long type
Posted by Aleksey Shipilev <al...@gmail.com>.
Xiaoming,
Well, it looks like I get it.
You're trying to optimize I8 multiplication, which is not directly
supported on ia32. The original code generates I8PseudoInst for this
multiplication and then lowers it in Ia32I8Lowerer.cpp. But you can
operate on I4 only, so you must drop out one of the branches in your
patch. Shame on me, I read the patch inattentively...
I haven't idea what to do with I8Lowerer, looks like we need to handle
2^k multiplications and divisions there too. Let's handle I4 in
InstCodeSelector for now, then open a new JIRA for long operations. We
can back there some day.
Thanks,
Aleksey.
On Thu, Jul 10, 2008 at 5:04 PM, Aleksey Shipilev
<al...@gmail.com> wrote:
> Xiaoming, a couple of questions:
> 1. Is this a reason for ICU-related failure?
> 2. Does it reproduce in Java code for you?
>
> I had written the test [1] and run it with HARMONY-5901 onboard:
> $ ../builds/shade.5901/bin/java -Xem:opt testShift
> a = -70
> b = -1
>
> -Xem:opt used to make sure the method is compiled with OPT.
> I can't see the failure you mention... Can you describe the steps to reproduce?
>
> Thanks,
> Aleksey.
>
> [1]
> public class testShift {
>
> public static void main(String[] args) {
> long a = -70;
> long b = a >> 63;
>
> System.out.println("a = " + a);
> System.out.println("b = " + b);
> }
>
> }
>
> On Thu, Jul 10, 2008 at 4:45 PM, xiaoming gu <xi...@gmail.com> wrote:
>> With H5901-V2.patch, A/16=-5 if A=-70 and A is a long. After checking each
>> step, I found the mask
>> for a>>63 is not right, which should be 0xffffffffffffffff but is
>> 0xffffffff00000001. I tried many ways but couldn't
>> find the reason. Thanks for your help.
>>
>> Xiaoming
>>
>> On Thu, Jul 10, 2008 at 5:53 PM, Aleksey Shipilev <
>> aleksey.shipilev@gmail.com> wrote:
>>
>>> Hi, Xiaoming!
>>>
>>> Can you provide the exact test case?
>>> It's not obvious what do you try to say.
>>>
>>> Thanks,
>>> Aleksey.
>>>
>>> On Thu, Jul 10, 2008 at 1:36 PM, xiaoming gu <xi...@gmail.com>
>>> wrote:
>>> > Hi, all. I just got a problem with signed shift right problem.
>>> >
>>> > long a = 0x8000000000000000;
>>> > long b = a>>63; // b is 0xffffffffffffffff
>>> >
>>> > But if I use SAR to do the signed shift right in harmony internally, b is
>>> > 0xffffffff00000001.
>>> > I traced the code for a while and couldn't find the difference for the
>>> two
>>> > ways.
>>> >
>>> > Any idea? Thanks.
>>> >
>>> > Xiaoming
>>> >
>>>
>>
>
Re: a quick question for signed shift right for long type
Posted by Aleksey Shipilev <al...@gmail.com>.
Xiaoming, a couple of questions:
1. Is this a reason for ICU-related failure?
2. Does it reproduce in Java code for you?
I had written the test [1] and run it with HARMONY-5901 onboard:
$ ../builds/shade.5901/bin/java -Xem:opt testShift
a = -70
b = -1
-Xem:opt used to make sure the method is compiled with OPT.
I can't see the failure you mention... Can you describe the steps to reproduce?
Thanks,
Aleksey.
[1]
public class testShift {
public static void main(String[] args) {
long a = -70;
long b = a >> 63;
System.out.println("a = " + a);
System.out.println("b = " + b);
}
}
On Thu, Jul 10, 2008 at 4:45 PM, xiaoming gu <xi...@gmail.com> wrote:
> With H5901-V2.patch, A/16=-5 if A=-70 and A is a long. After checking each
> step, I found the mask
> for a>>63 is not right, which should be 0xffffffffffffffff but is
> 0xffffffff00000001. I tried many ways but couldn't
> find the reason. Thanks for your help.
>
> Xiaoming
>
> On Thu, Jul 10, 2008 at 5:53 PM, Aleksey Shipilev <
> aleksey.shipilev@gmail.com> wrote:
>
>> Hi, Xiaoming!
>>
>> Can you provide the exact test case?
>> It's not obvious what do you try to say.
>>
>> Thanks,
>> Aleksey.
>>
>> On Thu, Jul 10, 2008 at 1:36 PM, xiaoming gu <xi...@gmail.com>
>> wrote:
>> > Hi, all. I just got a problem with signed shift right problem.
>> >
>> > long a = 0x8000000000000000;
>> > long b = a>>63; // b is 0xffffffffffffffff
>> >
>> > But if I use SAR to do the signed shift right in harmony internally, b is
>> > 0xffffffff00000001.
>> > I traced the code for a while and couldn't find the difference for the
>> two
>> > ways.
>> >
>> > Any idea? Thanks.
>> >
>> > Xiaoming
>> >
>>
>
Re: a quick question for signed shift right for long type
Posted by xiaoming gu <xi...@gmail.com>.
With H5901-V2.patch, A/16=-5 if A=-70 and A is a long. After checking each
step, I found the mask
for a>>63 is not right, which should be 0xffffffffffffffff but is
0xffffffff00000001. I tried many ways but couldn't
find the reason. Thanks for your help.
Xiaoming
On Thu, Jul 10, 2008 at 5:53 PM, Aleksey Shipilev <
aleksey.shipilev@gmail.com> wrote:
> Hi, Xiaoming!
>
> Can you provide the exact test case?
> It's not obvious what do you try to say.
>
> Thanks,
> Aleksey.
>
> On Thu, Jul 10, 2008 at 1:36 PM, xiaoming gu <xi...@gmail.com>
> wrote:
> > Hi, all. I just got a problem with signed shift right problem.
> >
> > long a = 0x8000000000000000;
> > long b = a>>63; // b is 0xffffffffffffffff
> >
> > But if I use SAR to do the signed shift right in harmony internally, b is
> > 0xffffffff00000001.
> > I traced the code for a while and couldn't find the difference for the
> two
> > ways.
> >
> > Any idea? Thanks.
> >
> > Xiaoming
> >
>
Re: a quick question for signed shift right for long type
Posted by Aleksey Shipilev <al...@gmail.com>.
Hi, Xiaoming!
Can you provide the exact test case?
It's not obvious what do you try to say.
Thanks,
Aleksey.
On Thu, Jul 10, 2008 at 1:36 PM, xiaoming gu <xi...@gmail.com> wrote:
> Hi, all. I just got a problem with signed shift right problem.
>
> long a = 0x8000000000000000;
> long b = a>>63; // b is 0xffffffffffffffff
>
> But if I use SAR to do the signed shift right in harmony internally, b is
> 0xffffffff00000001.
> I traced the code for a while and couldn't find the difference for the two
> ways.
>
> Any idea? Thanks.
>
> Xiaoming
>