Re: use ARM intrinsics in pg_lfind32() where available
John Naylor <john.naylor@enterprisedb.com>
From: John Naylor <john.naylor@enterprisedb.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-08-24T04:07:03Z
Lists: pgsql-hackers
On Tue, Aug 23, 2022 at 4:15 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Mon, Aug 22, 2022 at 11:50:35AM +0700, John Naylor wrote: > > 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. The important thing is: if we compile with __aarch64__ as a target: - Will the compiler emit the intended instructions from the intrinsics without extra flags? - Can a user on ARM64 ever get a runtime fault if the machine attempts to execute NEON instructions? "I have been able to compile for __aarch64__ without __ARM_NEON" doesn't really answer that question -- what exactly did this entail? > > 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. I took a quick look around at Debian code search, *BSD, Apple, and a few other places, and I can't find it. Then, I looked at the discussions around commit 5c7603c318872a42e "Add ARM64 (aarch64) support to s_lock.h", and the proposed patch [1] only had __aarch64__ . When it was committed, the platform was vaporware and I suppose we included "__aarch64" as a prophylactic measure because no other reason was given. It doesn't seem to exist anywhere, so unless someone can demonstrate otherwise, I'm going to rip it out soon. [1] https://www.postgresql.org/message-id/flat/1368448758.23422.12.camel%40t520.redhat.com -- John Naylor EDB: http://www.enterprisedb.com
Commits
-
Further code review of port/simd.h
- 865424627db6 16.0 landed
-
Fix broken cast on MSVC
- c6a43c25a8ba 16.0 landed
-
Remove unused symbol __aarch64
- 4112e39f70ee 16.0 landed