Re: [PATCH 1/2] doc: describe the lane freedom of the widen_ssum and widen_usum patterns

> I wonder if this is a step in the correct direction, see PR67612 where
> we want to apply a SLP pattern to exercise the actual lane mapping
> done.

> Do we want to have separate optabs for this?  IMO what you document
> would be better named reduc_widen_ssum_optab (as opposed to
> reduc_widen_ssum_scal_optab or widen_ssum_optab).  Where the _scal
> variant would be expected to accumulate to a scalar (or lane zero),
> the reduc_*_optab would be free in how to accumulate lanes and
> the widen_ssum_optab would lay out exactly which source lanes are
> summed to which destination lanes (I hope ISAs have matching behavior
> here).

I would be very much in favor of a separate optab rather than narrowing=20
widen_[us]sum's scope.  You could argue that sum vs plus is already an=20
inconsistency, though.
Last year I experimented with making widen_[us]sum available to RVV. =20
That necessitated a few changes in the vectorizer (we don't expect=20
"SLP-style" "number of lanes stays the same" everywhere) but it's not=20
that big of a change.

Of course the general question remains where the widening should=20
actually be recognized.  For riscv it works quite well doing it "late".

--=20
Regards
 Robin