-
Enhancement
-
Resolution: Unresolved
-
P3
-
repo-panama
-
None
In places where exceptional shuffle indexes are dynamically processed, allow the user 2 or 3 options about how to process them, so as to give finer control over the performance model.
As one option, shuffle indexes can be explicitly wrapped. In the usual case (which is not the fully general case), VLENGTH is a power of two, so wrapping simply involves disregarding some high bits. This is not Java-like when viewed as a variation of array indexing (where a[-1] never wraps), but it is somewhat Java-like in the very special case of integral shift operators, where "X<<N" will wrap the N value (mod 32 or 64). We can call this mode WRAP.
As another option, shuffle indexes can be explicitly checked. This leads to an exception being thrown on the first invalid index. We can call this mode CHECK.
Operations which consume shuffles generally default to CHECK. Operations with two-vector inputs use the "invalid bit" to steer data, but then do a WRAP.
A third option for handling invalid indexes is to select no data, but instead interpolate a well-known value. Java uses 0 as the most common such value, since that is the default for otherwise uninitialized storage. (It also plays well with the FIRST_NONZERO operation in VectorOperations.) We can call this mode ZERO.
The modes WRAP, CHECK, and ZERO all correspond to known hardware behaviors, and so are plausible additions to a performance-oriented user model.
Therefore, single-vector shuffle operations should take an optional parameter (via method overloads) which is an enum (or even small integer) which encodes the above three modes, or at least WRAP and CHECK.
The default setting of this parameter should be something that is reasonably performant, that is Java-like, and that doesn't hide too many bugs. It doesn't need to be maximally performant, since the user can control it.
Perhaps a fourth option DONT_CARE would make sense: It would permit the optimizer to "pick any value" for an out-of-range index, and let it pick whatever instruction seems fastest. This is not Java-like at all, and may also not be necessary as an escape hatch, if WRAP is known to be fast. (Note that WRAP and DONT_CARE both hide bugs since you can't tell from the output of the shuffle whether your indexes were out of bounds or not.).
Ref: http://cr.openjdk.java.net/~kkharbas/vector-api/CSR/javadoc.02/jdk.incubator.vector/jdk/incubator/vector/VectorShuffle.html
As one option, shuffle indexes can be explicitly wrapped. In the usual case (which is not the fully general case), VLENGTH is a power of two, so wrapping simply involves disregarding some high bits. This is not Java-like when viewed as a variation of array indexing (where a[-1] never wraps), but it is somewhat Java-like in the very special case of integral shift operators, where "X<<N" will wrap the N value (mod 32 or 64). We can call this mode WRAP.
As another option, shuffle indexes can be explicitly checked. This leads to an exception being thrown on the first invalid index. We can call this mode CHECK.
Operations which consume shuffles generally default to CHECK. Operations with two-vector inputs use the "invalid bit" to steer data, but then do a WRAP.
A third option for handling invalid indexes is to select no data, but instead interpolate a well-known value. Java uses 0 as the most common such value, since that is the default for otherwise uninitialized storage. (It also plays well with the FIRST_NONZERO operation in VectorOperations.) We can call this mode ZERO.
The modes WRAP, CHECK, and ZERO all correspond to known hardware behaviors, and so are plausible additions to a performance-oriented user model.
Therefore, single-vector shuffle operations should take an optional parameter (via method overloads) which is an enum (or even small integer) which encodes the above three modes, or at least WRAP and CHECK.
The default setting of this parameter should be something that is reasonably performant, that is Java-like, and that doesn't hide too many bugs. It doesn't need to be maximally performant, since the user can control it.
Perhaps a fourth option DONT_CARE would make sense: It would permit the optimizer to "pick any value" for an out-of-range index, and let it pick whatever instruction seems fastest. This is not Java-like at all, and may also not be necessary as an escape hatch, if WRAP is known to be fast. (Note that WRAP and DONT_CARE both hide bugs since you can't tell from the output of the shuffle whether your indexes were out of bounds or not.).
Ref: http://cr.openjdk.java.net/~kkharbas/vector-api/CSR/javadoc.02/jdk.incubator.vector/jdk/incubator/vector/VectorShuffle.html