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 ;) -- Regards Robin
