Feature Request: Add cross-lane horizontal reduction methods (e.g., .reduce_sum(), .reduce_max()) to SimdBase / Simd vector types

[Mnwa]

Feature Description

With fearless_simd solidifying its generic traits and racing toward a stable v1.0 release, it would be extremely valuable to have native, cross-lane horizontal reduction operations built directly into the crate's vector APIs.

Specifically, adding methods such as .reduce_sum(), .reduce_min(), .reduce_max(), and logical reductions like .any() / .all() on boolean masks.

Motivation & Use Case

When performing numerical algorithms (like calculating dot products, vector averages, or image processing bounds), the standard optimization pattern relies on accumulating data vertically across independent vector lanes within the loop, followed by a single horizontal reduction to a scalar at the very end.

Currently, std::simd supports this directly via vector.reduce_sum(). For fearless_simd to serve as a complete, drop-in replacement on stable Rust, users shouldn't have to break abstraction or manually write platform-specific shuffles/hadds to extract a single scalar sum from a generic vector type.

Providing this inside SimdBase or via a dedicated reduction trait would significantly improve ergonomics for generic SIMD code.

Proposed API / Design

Ideally, these operations would be exposed through the recently unified trait architecture (like SimdBase).

pub trait SimdBase {
    type Element;
    // ... existing items

    /// Sums all lanes in the vector horizontally.
    fn reduce_sum(self) -> Self::Element;

    /// Finds the maximum value among all lanes.
    fn reduce_max(self) -> Self::Element;

    /// Finds the minimum value among all lanes.
    fn reduce_min(self) -> Self::Element;
}

Alternatives Considered

1. Manual Array Reinterpretation: Extracting the vector to an array via .to_array() (or using upcoming as_array methods) and using .iter().sum(). However, this relies heavily on the compiler to optimize out memory operations, which can sometimes fail to lower cleanly to native hardware horizontal addition instructions (like HADDPS on x86 or ADDV on AArch64).
2. Platform-Specific Intrinsics: Writing custom matching logic per SIMD architecture level (Sse2, Avx2, Neon), which completely defeats the purpose of the beautiful generic abstractions fearless_simd provides.

[Shnatsel]

Extracting the vector to an array via .to_array() (or using upcoming as_array methods)

We do not have .to_array() methods, and never did. This is clearly LLM-written and contains hallucinations.

[Shnatsel]

I've found yet more errors by reading this further. Please do your own research instead of delegating design to error-prone LLMs.

[Mnwa]

Sorry, just u32x8.iter().sum() works in my case. But it will be better to have an reduce acc methods

[Shnatsel]

Even a quick query to chatgpt shows that doing this for u32x8 is easy, but there are non-trivial design considerations for u8 and floats: https://chatgpt.com/share/6a857edc-b904-83eb-9173-630ddb880dfa

more on floats: https://orlp.net/blog/taming-float-sums/

[Mnwa]

I think it's ok to use the iter().sum() in some hard cases at first inside library and step by step impl the faster algs for targets and primitives

[Mnwa]

Also wide already have that methods and portable simd too https://docs.rs/wide/latest/src/wide/f32x8_.rs.html#441-459

[Mnwa]

@Shnatsel is it possible to plan that? Until it's implemented I should do some stuff like that. Also some kind of reduce methods already realized in wide and pulp libs.

[Dr-Emann]

Personally interested in a reduce_sum_widened as well. It's nice to have a full vector of u8s which I've accumulated, and I want their sum in a u16, since any of my elements could be as big as 255.

[Shnatsel]

You can do that today with widen, reduce_sum, widen, reduce_sum sequence; the length varies depending on the element and . At some point we hit i128/u128 and can't go any further so it's tricky to implement generically.

[Shnatsel]

I left my previous comment in a hurry, sorry. Let me try again.

To get reduce_sum_widened behavior you can simply widen your u8 vector, add the halves together and then reduce_sum the result.

A single widen is enough for sum because a single vector can store up to 64 elements (512 bits with u8 elements) while u16 represents 256 times the range of u8, and 64 <= 256. For wider elements the range increase is even larger.

I'm not sure this deserves its own op since it's easy to compose from existing ones already. The only caveat is that it doesn't handle summing u64/i64 into a u128/i128, but that would have to be fully scalarized anyway, so I'm not sure if that's of any use.

reduce_product_widened is trickier since it needs widening at every step. You have to run widen followed by multiplication in a loop. All 128-bit vectors reduce to u128 but there is no way to represent multiplying together all elements of a 256-bit or 512-bit vector without the possibility of overflow somewhere. So it's not really possible in the general case, but you can still make certain subsets work.

So I think a general widening product is not something we can provide, but I could be convinced about widening sum.

[dzaima]

NEON has instructions specifically for widening integer summing, addlv (among other neat widening stuff, esp. widening accumulating in a loop, though general optimal widening summing across a loop is super messy).

On x86 there's options for widening summing better than separate widen+sum for all ≤32-bit types:

• u8: psadbw, unsigned-widening-sums groups of 8 bytes, then regular 64-bit sum (also trivially useful for non-widening 8-bit)
• i16: pmaddwd with 1 for widening-signed-pairwise sum, then regular 32-bit sum
• u32: reinterpret as u64 and do (a & 0xFFFFFFFF) + (a>>32), then regular 64-bit sum, general option for unsigned
• i8/u16/i32: the above can be used via toggling the sign bit and adding bias to the final result (u16 may or may not be better as u32-reinterpreted (a & 0xffff) + (a>>16)?)
  LLVM seems to optimize to these or similar for some cases, but not for others.