On Tue, Aug 23, 2022 at 4:15 AM Nathan Bossart <nathandboss...@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
