On Wed, 9 Feb 2022 21:36:01 GMT, Paul Sandoz <psan...@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
