Re: use ARM intrinsics in pg_lfind32() where available
От | John Naylor |
---|---|
Тема | Re: use ARM intrinsics in pg_lfind32() where available |
Дата | |
Msg-id | CAFBsxsEvzdUZe3WqojHDTT28HOopR4eibARdH2eCkdBEnM__qQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: use ARM intrinsics in pg_lfind32() where available (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: use ARM intrinsics in pg_lfind32() where available
|
Список | pgsql-hackers |
On Sat, Aug 20, 2022 at 5:28 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Fri, Aug 19, 2022 at 02:26:02PM -0700, Andres Freund wrote: > > Are you sure there's not an appropriate define for us to use here instead of a > > configure test? E.g. > > > > echo|cc -dM -P -E -|grep -iE 'arm|aarch' > > ... > > #define __AARCH64_SIMD__ 1 > > ... > > #define __ARM_NEON 1 > > #define __ARM_NEON_FP 0xE > > #define __ARM_NEON__ 1 > > .. > > > > I strikes me as non-scalable to explicitly test all the simd instructions we'd > > use. > > Thanks for the pointer. GCC, Clang, and the Arm compiler all seem to > define __ARM_NEON, so here is a patch that uses that instead. Is this also ever defined on 32-bit? If so, is it safe, meaning the compiler will not emit these instructions without additional flags? I'm wondering if __aarch64__ would be clearer on that, and if we get windows-on-arm support as has been proposed, could also add _M_ARM64. I also see #if defined(__aarch64__) || defined(__aarch64) in our codebase already, but I'm not sure what recognizes the latter. -- John Naylor EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: