[vector] Remove div operation from Byte/Short/Int/LongVector

[John Rose]

On Apr 22, 2020, at 2:00 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> I am more confident it should be possible to support both papering over differences, if any, with regards to div by 0.

Thank you Paul.  I’ll try to keep up in the future!

A comment on the point about n/0:  Different platforms have different
conventions about divide-by-zero.  As I said in my previous note,
the V-API is a compromise between Java primitive semantics (as
distributed across idealized portable vector lanes) and the specific
capabilities of platforms it compiles to.  Divergences appear among
these various reference points, either as differences of behavior
or different capabilities, and the V-API tries to strike a useful
compromise among these divergences.  Java primitive semantics
are the “center of gravity” here, so that we are likely to do something
different from Java only if the various hardware platforms provide
a “strong pull” to diverge from Java’s rules.

The advantage to following Java’s rules precisely is that there is
then a clear refactoring between a scalar loop written in Java and
a vectorized loop doing the same work, but faster.  If you had to
use a different rounding mode or exception model in order to
vectorize a Java loop, you’d have to work a lot harder, or be
willing to disappoint your users with more variable behavior.
In addition, the V-API implementation code would have to be
more complex, since the scalar fallback code would have to
implement the special semantics.  I would say that pulling away
from Java semantics only makes sense if there are *no* Java
semantics to start with (as in the case of floating point classification,
or carryless multiply, or AES-step, or maybe bit permutations).
And even in that case it would be prudent to *also* supply scalar
Java primitives corresponding to the “vector specific” operations,
if they are non-trivial.

In the case of divide-by-zero, there is no consensus among vector
platforms, so (as usual) Java compatibility supplies the rule.  This
means that vectorized integer division can throw a Java-specific
exception (ArithmeticException, to be precise).  Even if a platform
supports native division, it clearly knows nothing about Java’s
rules, so the V-API requires Java code for integer division which
includes a slow path like this:

  VectorMask<Long> eqz = divisor.eq((long)0);
  if (eqz.anyTrue())     throw that.divZeroException();

The end user may also have included such a test, and the JIT
should (eventually) be able to fold up such tests when they are
redundant.  For example:

  VectorMask<Long> ok = y.ne(y.broadcast(0));
  LongVector overflows = y.broadcast(Long.MAX_VALUE);
  return overflows.blend(ok, x.div(y, ok));

Here, there will be an internal test, inside x.div(y), against
a mask with the same value as ok.not().  That should make
possible for the JIT to infer that the built-in slow path cannot
be reached, so the user-requested fast path is used instead.

Some platforms provide an alternative semantics involving
a substitute value.  ARM arbitrarily substitutes zero as the result of
any n/0.  Java code can ask for such behavior, and hope (with time)
that the JIT will fold up the code to a single native instruction.
The “ask” would look similar to the previous code example:

  VectorMask<Long> ok = y.ne(y.broadcast(0));
  LongVector zeroes = y.broadcast(0);  // ARM replacement value
  return zeroes.blend(ok, x.div(y, ok));

For platforms which don’t support native integer division at
all, other tactics can be used, such as substituting floating point
division (but only after a range check has ensured that there
will be no loss of precision) or using a subroutine library, such
as SVML.  Or, as a last resort (but a first prototype), unwinding
the vector code back to scalar code.  That last resort seems to
be part of the cost of doing business with certain operations,
not only division but also certain cases of scatter or gather.

Anyway, that’s the theory so far, as I see it.

— John