https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to ktkachov from comment #9) > (In reply to Tamar Christina from comment #8) > > (In reply to ktkachov from comment #7) > > > Could this be extended to scale Neon intrinsics code to SVE by > > > re-vectorising and treating the 128-bit Neon lane as a Q-word element of > > > a > > > wider SVE vector? I think SVE2.1 adds instructions to support that model. > > > > For some, In particularly only those that have been lowered to generic > > constructs in GIMPLE. > > > > My current WIP patch already can change the example input Adv. SIMD code > > into SVE if one does +sve. > > > > However if you use something like FCMLA it won't work since the SVE variant > > of FCMLA is a differently name gimple call. > > > > Yeah agreed. What about IFN_*s? We fold some Neon intrinsics to IFNs (we > have a few more folding opportunities missing, but that can be fixed > independently) and those IFNs usually have SVE/SVE2 expansions so I'd expect > the vectoriser to handle these without too much trouble? For load IFNs we'll have to teach dataref analysis what they mean. Like load lanes, gathers etc. And then during SLP build we'd likely want to materialize the lane permutes in the load nodes. Reduction IFNs would need to be recognized and the PHI nodes that feed them marked as reductions. Reductions need extra work anyway since the reduction can happen outside of the loop compared to scalar code where it would have been in the loop. Dataflow IFNs are straight forward and should just work. I think for intrinsics that aren't lowered in gimple (and it's not really feasible to lower all of them) we're going to need a mapping table and/or rename the sve and adv. Simd internal names to the same thing so we can differentiate them by type/modes only. As long as they are marked pure+const the vectorizer should have no problem with them I think. Widening and narrowing IFNs or operations will be problematic as adv. Simd uses top/bottom while sve even/odd. The vectorizer would need proper support for even/odd first I think and based on that we could make it work. This is the biggest unknown to me atm.
