Re: use ARM intrinsics in pg_lfind32() where available

On Thu, Aug 25, 2022 at 10:38:34AM +0700, John Naylor wrote:
> On Thu, Aug 25, 2022 at 1:01 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> On Wed, Aug 24, 2022 at 11:07:03AM +0700, John Naylor wrote:
>> > - Can a user on ARM64 ever get a runtime fault if the machine attempts
>> > to execute NEON instructions?
>>
>> IIUC yes, although I'm not sure how likely it is in practice.
>
> Given the quoted part above, it doesn't seem likely, but we should try
> to find out for sure, because a runtime fault is surely not acceptable
> even on a toy system.

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.
As originally suspected, I believe that simply checking for __aarch64__
would be sufficient, but I don't think it would be unreasonable to also
check for __ARM_NEON to be safe.

>> Interestingly, Clang still defines __ARM_NEON__ even when
>> +nosimd is specified.
>
> POLA violation, but if no one has complained to them, it's a good bet
> the instructions are always available.

Sorry, I should've been more specific. In my testing, I could include or
omit __ARM_NEON using +[no]simd, but __ARM_NEON__ (with two underscores at
the end) was always there. My brief research seems to indicate this might
be unique to Darwin, but in the end, it looks like __ARM_NEON (without the
trailing underscores) is the most widely used.

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