https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #15 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > OK, hopefully I understand now. Sorry for being slow. Not at all, Sorry if it came across a bit cranky, it wasn't meant that way! > If that's the condition we want to test for, it seems like something > we need to check in the vectoriser rather than the hook. And it's > not something we can easily do in the vector form, since we don't > track ranges for vectors (AFAIK). Ack, that also tracks with what I tried before, we don't indeed track ranges for vector ops. The general case can still be handled slightly better (I think) but it doesn't become as clear of a win as this one. > You probably did so elsewhere some time ago, but what exactly are those > four instructions? (pointers to specifications appreciated) For NEON we use: https://developer.arm.com/documentation/ddi0596/2021-12/SIMD-FP-Instructions/ADDHN--ADDHN2--Add-returning-High-Narrow- https://developer.arm.com/documentation/ddi0596/2021-12/SIMD-FP-Instructions/UADDW--UADDW2--Unsigned-Add-Wide- In that order, and for SVE we use two https://developer.arm.com/documentation/ddi0602/2022-12/SVE-Instructions/ADDHNB--Add-narrow-high-part--bottom-- The difference between the SVE and the NEON versions is that the SVE version does even/odd and the NEON the typical first N, last N element wise operation. At the moment the vectorizer doesn't know anything at all about SVE's even and odd instructions. But if we create B we should create T as well.
