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