Vector.shiftER, Vector.shiftEL not working as expected.

[Richard Startin]

I think I may have confused similarly named instructions and want to clarify:


- As you point out, VPSLLD and VPSRLD perform bit shifts on packed integers, and these instructions correspond to shiftL and shiftR respectively on the API (and presumably, VPSRAD for aShiftR).

- VPSLLDQ [1] shifts a vector word left by a whole number of bytes - which would always be a multiple of 4 for IntVector<S> - will this be the intrinsic implementation of shiftEL?


I don't think I understand your last point. If I shift left (element wise) I expect to remove the left-most element. Is this how it will work, as in the test case, going forwards? Or the other way round?



[1] http://www.felixcloutier.com/x86/PSLLDQ.html


<http://www.felixcloutier.com/x86/PSLLDQ.html>
Thanks,

Richard

________________________________
From: Paul Sandoz <paul.sandoz at oracle.com>
Sent: 10 October 2017 22:14:37
To: Richard Startin
Cc: Razvan Lupusoru; panama-dev at openjdk.java.net
Subject: Re: Vector.shiftER, Vector.shiftEL not working as expected.


> On 10 Oct 2017, at 12:01, Richard Startin <richard at openkappa.co.uk> wrote:
>
> Hi Razvan, Paul,
>
> Thanks, I was expecting PSLLD/PSRLD for packed integers as per the start of my email.

Ok, i expect the following methods on IntVector (and friends) to be made intrinsic at some point leveraging such instructions:

  public IntVector<S> shiftL(int s)

  public IntVector<S> shiftR(int s)

  public IntVector<S> aShiftR(int s)


> I am experimenting to see how fast integer compression algorithms such as [1] can go in Java. I'll keep an eye on the project and have another go when more has been intrinsified.
>

Thanks!


> Thanks for pushing the fix.
>

No problem. I made a choice on the lane L/R direction based on ascending indexes rather than descending indexes, as you expected in your test case, that seems more intuitive in terms of order.

Paul.


> [1] https://arxiv.org/pdf/1401.6399.pdf
>