RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

[Bernd Eckenfels]

Hello,

Maybe offer operations which can do all variants (shift, roll, signed/unsigned) - maybe even with support for byte/int conversion? Any of those bit fiddling activities in a pipeline can benefit from vectoring.

And also, the Javadoc can list the equivalent operator based code and maybe bit pattern examples for all overflow cases.

And also.. the unit tests can double as snipped code.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Jie Fu <jiefu at openjdk.java.net>
Gesendet: Monday, April 18, 2022 3:51:40 AM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Betreff: Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

On Sun, 17 Apr 2022 23:53:49 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> According to JLS section 5.8, any operand in a numeric arithmetic context undergoes a promotion to int, long, float or double and the operation is only defined for values of the promoted types. This means that `>>>` is not defined for byte/short values and the real behaviour here is that `src[i]` get promoted to int by a signed cast before entering the unsigned shift operation. This is different from `VectorOperators.LSHR` which is defined for byte/short element types. The scalar code does not do a byte unsigned shift but an int unsigned shift between a promotion and a narrowing cast, the explicit cast `(byte)` notifies the user of this behaviour.

I can't understand why people can't use `>>>` for negative bytes/shorts.
 - Does the spec forbidden this usage?
 - Is there any compile error?
 - Is there any runtime error?
 - Is the behavior to be undefined?

The JLS you mentioned actually defines how to compute `>>>` for bytes/shorts in Java, which applies to both positive and negative bytes/shorts.
 - First, it gets promoted.
 - Then, do something else.

So I disagree with you if the JLS spec doesn't say people are not allowed to use `>>>` for negative bytes/shorts.




>
> Secondly, consistency is the key, having a byte unsigned shift promoting elements to ints is not consistent, I can argue why aren't int elements being promoted to longs, or longs being promoted to the 128-bit integral type, too.
>


Well, this kind of behavior was specified by the Java spec rules many years ago.
We have to just follow these rules if you can't change the specs.


> Finally, as I have mentioned in #7979, this usage of unsigned shift seems more likely to be a bug than an intended behaviour, so we should not bother to optimise this pattern.

Since the behavior of shift operations is clearly defined by the Java specs and supported by the language, how do you know there is no one to use it intendedly?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276