Signed-off-by: John Pennycook <john.pennycook@intel.com>

Splits the functionality of a regular reducer across two classes:

1) reducer contains the work-item's private data and exposes the
   subscript operator ([]) to access an individual element.

2) reducer_element contains a pointer to one element from the
   reducer, and exposes the regular combine interface.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

The specialization allows the type of the reduction (span<T, Extent>)
to be separate from the type of the span (T). T is used to determine
the reduction algorithm that should be used, and to create temporary
storage.

A new static member function "num_elements" is added to all reduction_impl
specializations to distinguish between scalar reductions and array reductions.
A scalar reduction (all existing implementations of reduction_impl) always
has (num_elements == 1); an array reduction (this new specialization) has
(num_elements == Extent), where Extent is the extent of the span.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Each of the existing reduction implementations (for a single reduction object)
can be extended to support spans by looping over the number of elements in the
reduction.

If (num_elements == 1), the loop has a single iteration and degenerates to the
behavior of the reduction implementation prior to this commit. If
(num_elements > 1), the loop iterates over each reduction element in turn.

Note that the getElement() function allows the scalar and array reduction
implementations to be the same without specializing for either case, and
allowing difference in storage (a single T vs an array of Ts). This is
especially convenient because a scalar reduction is equivalent to an array
reduction with a single element.

If (num_elements > 1), the implementation currently reduces each element
separately. This allows array reductions to use the same amount of work-group
local memory as a scalar reduction using the same T, but at the expense of
additional synchronization calls.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Necessary because span.hpp is only available >= C++17.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Co-authored-by: Vyacheslav Klochkov <vyacheslav.n.klochkov@intel.com>

This commit refactors the reduction implementation to avoid code duplication,
and additionally makes a number of changes to the class hierarchy for future
extensibility.

All functionality and member variables expected to be common to all reductions
is moved to a common base class (reduction_impl_common). The existing
reduction_impl_base is unsuitable for this purpose because it was deliberately
designed not to be a template class.

The reduction_impl is now templated on a reduction algorithm, with any
functionality related to the current (default) algorithm encapsulated in the
default_reduction_algorithm class. This template is carried from the reduction
to any reducers it creates, enabling future specialization of both reduction
and reducer for interesting combinations of type, extent and properties.

The reducer class is simplified using CRTP to avoid duplicate definitions of
combine() and atomic_combine() for scalar and array reductions.

The notion of a reducer's "dimensionality" is now tied to the dimensionality of
the reduction being performed (i.e. 0 for scalars, 1 for spans) and not to the
dimensionality of the input accessor/buffer. This will simplify extending
reductions to true multi-dimensional array reductions (i.e. with md_span).

Signed-off-by: John Pennycook <john.pennycook@intel.com>

The definition of atomic_combine() did not correctly compute the offsets for
reductions with Extent > 1. This was hidden by a bug in the associated tests.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Scalar and array (span) reductions require different algorithms,
preventing the original scalar reduction code from being generalized to cover
spans. Specifically, the original scalar reduction code assumes that each stage
of a reduction (initializing reducers, combining reducers in local memory,
writing reducers back to global memory) can be applied to all reductions in a
pack at the same time. This is incompatible with the current implementation
of array reductions, which iterates over all elements of a span in turn at each
stage.

The implementation introduced in this commit filters the scalar and array
reductions from the reduction pack and handles them separately. All scalar
reductions are handled in parallel (as before), while each array reduction
is handled separately.

In future, the code handling the reduction packs could be generalized to
handle more reduction/reducer types while making less assumptions about
the reduction algorithm.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Previously assumed specific reducer implementation and template arguments.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Co-authored-by: Vyacheslav Klochkov <vyacheslav.n.klochkov@intel.com>

Co-authored-by: Vyacheslav Klochkov <vyacheslav.n.klochkov@intel.com>

Co-authored-by: Vyacheslav Klochkov <vyacheslav.n.klochkov@intel.com>

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Co-authored-by: Vyacheslav Klochkov <vyacheslav.n.klochkov@intel.com>

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Signed-off-by: John Pennycook <john.pennycook@intel.com>

std::tuple is still used for reducers (as in the original code).

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Signed-off-by: John Pennycook <john.pennycook@intel.com>

span<T, 1> is still an array reduction.

Signed-off-by: John Pennycook <john.pennycook@intel.com>