RFR: 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors

[John R Rose]

On Wed, 9 Feb 2022 21:36:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> …ArgumentExcept on zero vectors
> 
> This PR fixes issues for reduction using FIRST_NONZERO and adds tests. The testing infrastructure is generalized to reduction functions and tests for min/max reductions are updated to use that.

Wow good catch.

A single vector operation is almost never a whole algorithmic step, but rather a part of a larger one, across an array, for which the vector is a "window" viewing part of the the array, either VLEN elements, or (in the case of masking) a lesser number.

Put another way, doing a task on VLENGTH>2 elements should always be refactorable as a pair of similar tasks on a pair of shorter VLENGTH/2 vectors and vice versa.

Put yet another way, vector operations should support grouping and ungrouping transformations.

In the case of reductions, a longer reduction of the form `R[op](a,b…,c,d…)` should always decompose into shorter ones, as `R[op](a,b…) op R[op](c,d…)`, and vice versa.  Suppose VLENGTH=8; a reduction over a 13-element array should always be vectorizable as an 8-way reduction followed by a masked reduction of the remainder, followed by a scalar reduction.  That goes for `FIRST_NONZERO` as well as (most) other ops.  (Some ops like float add are only approximately associative.)

You can consider this a public service announcement reminding us why throwing on an edge condition from a vector operation is probably always wrong.

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

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