Re: use ARM intrinsics in pg_lfind32() where available

From: Andres Freund <andres(at)anarazel(dot)de>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, john(dot)naylor(at)enterprisedb(dot)com
Subject: Re: use ARM intrinsics in pg_lfind32() where available
Date: 2022-08-19 21:26:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2022-08-19 13:08:29 -0700, Nathan Bossart wrote:
> I've tested the patch on a recent macOS (M1 Pro) and Amazon Linux
> (Graviton2), and I've confirmed that the instructions aren't used on a
> Linux/Intel machine. I did add a new configure check to see if the
> relevant intrinsics are available, but I didn't add a runtime check like
> there is for the CRC instructions since the compilers I used support these
> intrinsics by default. (I don't think a runtime check would work very well
> with the inline function, anyway.) AFAICT these intrinsics are pretty
> standard on aarch64, although IIUC the spec indicates that they are
> technically optional. I suspect that a simple check for "aarch64" would be
> sufficient, but I haven't investigated the level of compiler support yet.

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

The story for the CRC checks is different because those instructions often
aren't available with the default compilation flags and aren't guaranteed to
be available at runtime.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Zhang 2022-08-19 22:27:04 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Previous Message Justin Pryzby 2022-08-19 21:18:24 FOR EACH ROW triggers, on partitioend tables, with indexes?