> 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 widen_[us]sum's scope. You could argue that sum vs plus is already an inconsistency, though. Last year I experimented with making widen_[us]sum available to RVV. That necessitated a few changes in the vectorizer (we don't expect "SLP-style" "number of lanes stays the same" everywhere) but it's not that big of a change. Of course the general question remains where the widening should actually be recognized. For riscv it works quite well doing it "late". -- Regards Robin
