> On 4 Aug 2026, at 16:19, Tamar Christina <[email protected]> wrote: > >> -----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. >
So as I’m not dealing day-to-day with the vectorizer, what would you recommend as the way forward here? Rename the optabs currently used for lane-agnostic reduction to reduc_widen_[us]sum_optab and implement those for aarch64 as in patch 2/2 and document the widen_[us]sum optabs as lane-preserving? Thanks, Kyrill > Thanks, > Tamar > >> -- >> Regards >> Robin
