On Thu, Nov 6, 2025 at 8:58 AM Robin Dapp <[email protected]> wrote: > > Grml, this is turning into a rabbit hole. > > The initial plan was to "just" support the widening shift optab for riscv. > This patch here was supposed to be the first step. The next patch adds > support > for n-n (SLP style) widening ops. > > But I'm realizing now that we should actually have all the checking and > fallback options that vectorizable_shift has, just also inside > vectorizable_conversion if the op is a widening shift... Not sure this is > worth at it the end of stage 1 when we can easily synthesize the widening > shift > on RTL level in the backend. > > Of course the long-term plan still is to move most of our RTL combinations > (single widening ops, double widening ops, narrowing ops) earlier in the > pipeline, making IFNs out of them but shift seems like the worst choice ;)
Yes, shifts are of the ugliest variant with all possible combinations of scalar vs. vector, constant vs. non-constant present/not present on targets ... Richard. > > -- > Regards > Robin >
