On Thu, Nov 6, 2025 at 10:59 AM Robin Dapp <[email protected]> wrote: > > > 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?
All of them that are available in lane-reducing form at least. IIRC we have some that apply to scalar operations as well, I'd not touch those for now, but possibly this is only highpart multiplication. We've stopped adding new tree codes for vector operations, transitioning the remaining legacy ones is good cleanup. > 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 think it makes sense to leave some freedom to combine/ra here, for example on x86 there's scalar-to-vector splat operands, but only for memory sources, so one you separate you need to make the splat explicit. IIRC the backend simply accepts a (vec_duplicate MEM) as operand here. > 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. Yes. > 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. IMO IFNs make sense when they map directly to optabs and from there directly to machine instructions (for at least some targets). IFNs have downsides as well - you already mentioned lack of IL verification and poor documentation (both can be fixed, of course). They are also calls, as opposed to new tree codes, which still some passes are not able to handle. Richard. > -- > Regards > Robin >
