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

From Nathan Bossart
Subject Re: use ARM intrinsics in pg_lfind32() where available
Date
Msg-id 20220826045115.GA1638993@nathanxps13
Whole thread Raw
In response to Re: use ARM intrinsics in pg_lfind32() where available  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: use ARM intrinsics in pg_lfind32() where available
List pgsql-hackers
On Fri, Aug 26, 2022 at 10:45:10AM +0700, John Naylor wrote:
> On Thu, Aug 25, 2022 at 11:57 AM Nathan Bossart
> <nathandbossart@gmail.com> wrote:
>> The ARM literature appears to indicate that Neon support is pretty standard
>> on aarch64, and AFAICT it's pretty common to just assume it's available.
> 
> This doesn't exactly rise to the level of "find out for sure", so I
> went looking myself. This is the language I found [1]:
> 
> "Both floating-point and NEON are required in all standard ARMv8
> implementations. However, implementations targeting specialized
> markets may support the following combinations:
> 
> No NEON or floating-point.
> Full floating-point and SIMD support with exception trapping.
> Full floating-point and SIMD support without exception trapping."

Sorry, I should've linked to the documentation I found.  I saw similar
language in a couple of manuals, which is what led me to the conclusion
that Neon support is relatively standard.

> Since we assume floating-point, I see no reason not to assume NEON,
> but a case could be made for documenting that we require NEON on
> aarch64, in addition to exception trapping (for CRC runtime check) and
> floating point on any Arm. Or even just say "standard". I don't
> believe anyone will want to run Postgres on specialized hardware
> lacking these features, so maybe it's a moot point.

I'm okay with assuming Neon support for now.  It's probably easier to add
the __ARM_NEON check if/when someone complains than it is to justify
removing it once it's there.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Small cleanups to tuplesort.c and a bonus small performance improvement
Next
From: Thomas Munro
Date:
Subject: wal_sync_method=fsync_writethrough