Re: vectorized CRC on ARM64 - Mailing list pgsql-hackers

From John Naylor
Subject Re: vectorized CRC on ARM64
Date
Msg-id CANWCAZZj35DGtjSX3umT1XHM49T4-v5ysc20TXPLcfn1oHGHfA@mail.gmail.com
Whole thread Raw
In response to Re: vectorized CRC on ARM64  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: vectorized CRC on ARM64
List pgsql-hackers
I wrote:
> autoconf support is a WIP, and I will share that after I do some
> testing on an Arm Linux instance.

I've only checked paths with objdump and debugging printouts (no perf
testing), but this seems to work in v3. My main concern now is whether
it's a maintenance hazard to overwrite CFLAGS_CRC in a separate check.

In master, we can have one of:

CFLAGS_CRC=""
CFLAGS_CRC="-march=armv8-a+crc+simd"
CFLAGS_CRC="-march=armv8-a+crc"

...and then based on that we set either USE_ARMV8_CRC32C or
USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK, and set PG_CRC32C_OBJS.

But below that, v3 runs a new test for pmull instructions with the
flag "-march=armv8-a+crc+simd+crypto" and if it links, it will reset
CFLAGS_CRC to that set of flags. That doesn't seem like the right
thing to do, but I don't see a good alternative. I suppose I could
sidestep that with function attributes, but that's not as well
supported. Another idea would be to turn the relevant line here

if test x"$Ac_cachevar" = x"yes"; then
  CFLAGS_CRC="$1"
  pgac_arm_pmull_intrinsics=yes
fi

...into CFLAGS_CRC="CFLAGS_CRC$1", where in this case $1 is just
"+crypto". That seems even more fragile, though.

--
John Naylor
Amazon Web Services

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: schema variables
Next
From: Daniel Gustafsson
Date:
Subject: Re: Eliminating SPI / SQL from some RI triggers - take 3