> -----Original Message----- > From: Robin Dapp <[email protected]> > Sent: 04 August 2026 15:07 > To: Richard Biener <[email protected]>; Kyrylo Tkachov > <[email protected]> > Cc: [email protected]; Tamar Christina <[email protected]>; > Robin Dapp <[email protected]> > Subject: 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 > 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". >
I think the widening and other similar optimizations need to stay in the vectorizer because for masked based targets like SVE if we generate an unpacking then the predicate needs to be unpacked too. That means any "late" detection has to clean up the predicate operations too which usually brings the chain out of what combine supports. But also by recognizing it In the vectorizer it allows us to cost alternate strategies like unpacking or using sparse vectors. So I don't think we can move this past costing as it has a significant effect on Codegen. Thanks, Tamar > -- > Regards > Robin
