Re: use ARM intrinsics in pg_lfind32() where available - Mailing list pgsql-hackers

From Andres Freund
Subject Re: use ARM intrinsics in pg_lfind32() where available
Date
Msg-id 20220819212602.brjkd6ppgbohvo6g@awork3.anarazel.de
Whole thread Raw
In response to use ARM intrinsics in pg_lfind32() where available  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: use ARM intrinsics in pg_lfind32() where available
List pgsql-hackers
Hi,

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
use.


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.

Regards,

Andres



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: FOR EACH ROW triggers, on partitioend tables, with indexes?
Next
From: David Zhang
Date:
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)