From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
---|---|
To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
Cc: | "Devulapalli, Raghuveer" <raghuveer(dot)devulapalli(at)intel(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Jesper Pedersen <jesperpedersen(dot)db(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Shankaran, Akash" <akash(dot)shankaran(at)intel(dot)com> |
Subject: | Re: Improve CRC32C performance on SSE4.2 |
Date: | 2025-06-18 10:18:15 |
Message-ID: | 877c19cpzs.fsf@163.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Naylor <johncnaylorls(at)gmail(dot)com> writes:
Hi,
>> Just be curious, what kind of optimization (like what -O2 does) could
>> mask this issue?
>
> In case Andy is asking about "how" rather than "under what
> circumstances", my guess is: -O1+ may have just chosen instructions
> that also happen to zero-extend, which are common. -O0 doesn't
> represent the naive straightforward structure of what the programmer
> wrote, it's more like an "exploded" representation suitable for later
> optimization passes. That's why it always looks goofy.
Thanks for the explaination!
>> > Replacing that with _mm512_zextsi128_si512 fixes the problem.
>
> Here's a patch for testing, which also reverts the previous
> workaround. Help welcome, but I still promise to test it in the near
> future regardless.
I verified the your patch, it works for me.
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2025-06-18 10:29:15 | Re: Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c) |
Previous Message | vignesh C | 2025-06-18 10:03:17 | Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly |