Re: vectorized CRC on ARM64

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: vectorized CRC on ARM64
Date: 2026-03-31 11:19:49
Message-ID: CANWCAZZj35DGtjSX3umT1XHM49T4-v5ysc20TXPLcfn1oHGHfA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v3-0001-Compute-CRC32C-on-ARM-using-the-Crypto-Extension-.patch text/x-patch 15.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-03-31 11:22:37 Re: Eliminating SPI / SQL from some RI triggers - take 3
Previous Message Pavel Stehule 2026-03-31 11:07:34 Re: proposal: schema variables