Re: use ARM intrinsics in pg_lfind32() where available

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:
> > 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?
>
> My testing with GCC and Clang did not require any extra flags. GCC appears
> to enable it by default for aarch64 [0]. AFAICT this is the case for Clang
> as well, but that is based on the code and my testing (I couldn't find any
> documentation for this).

I guess you meant this part: "‘simd’ Enable Advanced SIMD
instructions. This also enables floating-point instructions. This is
on by default for all possible values for options -march and -mcpu."

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

> > "I have been able to compile for
> > __aarch64__ without __ARM_NEON" doesn't really answer that question --
> > what exactly did this entail?
>
> Compiling with something like -march=armv8-a+nosimd prevents defining
> __ARM_NEON.

Okay, that's unsurprising.

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

> > 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.
>
> This is what I found, too, so +1. I've attached a patch for this.

Thanks, I'll push this soon. I wondered if the same reasoning applies
to __arm__ / __arm nowadays, but a quick search does indicate that
__arm exists (existed?), at least.

--
John Naylor
EDB: http://www.enterprisedb.com