https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 > > --- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #16) > > On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 > > > > > > --- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > > > (In reply to Richard Biener from comment #14) > > > > a >= 16 ? 0 : 32872 >> MIN (a, 15) (the MIN is still required to > > > > avoid requiring masking). > > > > > > Note maybe instead of MIN here we use `a & 0xf` since that will more > > > likely be > > > cheaper than a MIN. > > > > But it's incorrect (that's what I did originally). > > But `(a>= 16)? 0: (32872>> (a&0xf))` is correct. > > So is `(a>=16 ? 0 : 32872) >> ( a & 0xf)` . > > Or is it you want to avoid the conditional here. Yeah - at some point not trying to optimize the widening/shortening is going to be cheaper, no? Esp. if it is "just" because of GIMPLE being limited with no way to express the desired semantics for "out-of-bound" shifts (and no way to query target behavior for them of course). The widening/shortening might or might not have an effect on the VF (we don't know) and we don't (yet) compute if the target supports it. We could force a smaller vector size (if the target supports it) to avoid increasing the VF.
