https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127549
--- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> --- (In reply to Richard Biener from comment #1) > An uint16 seems to be _just_ enough here, but if pix[] are uint8 then not as > the difference can then be 256, times 16*16 is 65536. > > You could just demote the innermost loop accumulator, of course. > > I'd like to see how ugly this is going to be, of course - note we do not > have scalar patterns for PHIs (SLP patterns for the rescue? "Just" assign a > narrower vector type and "compensate"?) My current approach is to compute the range in vect_is_simple_reduction and annotate every involved statement with STMT_VINFO_REDUC_PREC. I'm now trying to figure out where to best "rewrite" the statements. Pattern matching (vect or SLP) don't feel right as we're not actually working on individual statements but on the full reduction cycle. It's not too difficult to just walk the reduction path, check whether each SAD_EXPR is supported in the narrower type and replace it. Right now I'm just doing SAD_EXPRs but plain PLUS/MINUS should be doable as well. I just wonder where to properly call such a rewrite function. It must obviously be before VF selection and included in retries etc. Maybe directly after analysis when starting over. But then we'd need a fallback to the original wide mode if analysis fails... and there might still be out-of-sync global state.
