> Yes, shifts are of the ugliest variant with all possible combinations of > scalar vs. vector, constant vs. non-constant present/not present on targets > ...
Plus now the complication of 5 widening variants, even/odd, hi/lo. Will most likely defer this to the next stage 1. In general, does it make sense to introduce IFNs for all our widening/narrowing ops? We have: - widening add, sub where only one source is widened - widening add, sub where both sources are widened - widening mul, widening mul with mixed signedness - widening fma, fnma, fms, fnms - widening plus reductions - narrowing shift right - widening (unsigned) left shift - narrowing "clip" Most of them allow immediate, scalar reg, and vector reg operands. I think that's pretty comparable to aarch64 and I know widening reductions are on Tamar's plan. Right now we don't have a lot of pain with combining e.g. a zero-ext and a plus into a widening add on RTL level and things generally work as intended. Apart from the ever-growing number of RTL patterns, that is ;) We switch between vector-vector and vector-scalar variants via late combine and RTL costing. I had one case in x264 where we could have introduced a widening FMA but only if the data range was narrow. During combine there wasn't enough range information. That's an obvious case where having a gimple representation helps. It feels more future proof to have IFNs but to me it is not really clear cut whether it's worth the extra effort early on. -- Regards Robin
