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
> <aleksey.shipilev@gmail.com> wrote:
> > Xiaoming, a couple of questions:
> > 1. Is this a reason for ICUrelated failure?
> > 2. Does it reproduce in Java code for you?
> >
> > I had written the test [1] and run it with HARMONY5901 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 <xiaoming.gu@gmail.com>
> wrote:
> >> With H5901V2.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 <xiaoming.gu@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
> >>> >
> >>>
> >>
> >
>
