| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | Haibo Yan <tristan(dot)yim(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: vectorized CRC on ARM64 |
| Date: | 2026-03-18 06:52:37 |
| Message-ID: | CANWCAZZ0CVw2+aueKYqWc2fwk7TJ6yg8gn6Y5MrEUR-RuNePOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 18, 2026 at 10:34 AM Haibo Yan <tristan(dot)yim(at)gmail(dot)com> wrote:
>
> Hi John
>
> Thank yo for working on this. I had one question about the mixed use of intrinsics and inline asm here.
> Since the implementation already uses NEON intrinsics such as vld1q_u64, I was wondering why the pmull / pmull2 + eor helpers still need to be inline asm rather than intrinsics.
>
> Is that due to compiler/toolchain support, or because the intrinsic-based version produced noticeably worse code?
I answered that in the email you replied to, re-quoted here:
> To follow-up for curiosity's sake, [1] says that Apple chips can issue
> PMULL + EOR as a single uop if they are next to each other in the
> instruction stream.
> [1] https://dougallj.github.io/applecpu/firestorm.html
I don't know if that's relevant for current server hardware, so it
could be pointless. I'm personally not a fan of inline assembly, but I
also didn't yet want to put in the effort to alter generated code. I
don't think it would be very hard to do, however.
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-03-18 06:59:00 | Re: Fix uninitialized xl_running_xacts padding |
| Previous Message | Peter Smith | 2026-03-18 06:40:48 | Re: Skipping schema changes in publication |