Re: use ARM intrinsics in pg_lfind32() where available
От | Nathan Bossart |
---|---|
Тема | Re: use ARM intrinsics in pg_lfind32() where available |
Дата | |
Msg-id | 20220822211547.GA1126462@nathanxps13 обсуждение исходный текст |
Ответ на | Re: use ARM intrinsics in pg_lfind32() where available (John Naylor <john.naylor@enterprisedb.com>) |
Ответы |
Re: use ARM intrinsics in pg_lfind32() where available
|
Список | pgsql-hackers |
On Mon, Aug 22, 2022 at 11:50:35AM +0700, John Naylor wrote: > On Sat, Aug 20, 2022 at 5:28 AM Nathan Bossart <nathandbossart@gmail.com> wrote: >> 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 haven't been able to enable __ARM_NEON on 32-bit, but if it is somehow possible, we should probably add an __aarch64__ check since functions like vmaxvq_u32() do not appear to be available on 32-bit. I have been able to compile for __aarch64__ without __ARM_NEON, so it might still be a good idea to check for __ARM_NEON. So, to be safe, perhaps we should use something like the following: #if (defined(__aarch64__) || defined(__aarch64)) && defined(__ARM_NEON) > I also see #if defined(__aarch64__) || defined(__aarch64) in our > codebase already, but I'm not sure what recognizes the latter. I'm not sure what uses the latter, either. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: