Re: call popcount32/64 directly on non-x86 platforms

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: call popcount32/64 directly on non-x86 platforms
Дата
Msg-id CAApHDvqNoBg0_yEW8fQQCMH0p=-TEZR1f-ZDJphKcifrKPmYsg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: call popcount32/64 directly on non-x86 platforms  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: call popcount32/64 directly on non-x86 platforms  (John Naylor <john.naylor@enterprisedb.com>)
Re: call popcount32/64 directly on non-x86 platforms  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Fri, 13 Aug 2021 at 01:28, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Fri, 13 Aug 2021 at 01:11, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > So when on MSVC, you don't have to check CPUID for support?
>
> That still needs to be checked in MSVC and as far as I can see it is
> being properly checked.

Something there that might cause confusion is we do a configure check
to see if popcntq works and define HAVE_X86_64_POPCNTQ if it does.
I'm still a bit confused at why we bother doing that. Surely it just
means that if the build machine does not have popcntq that we'll
always use pg_popcount64_slow, regardless if the machine that's
actually running the code has popcntq.

Maybe you saw that there's no such equivalent test when we set
HAVE_X86_64_POPCNTQ for MSVC on x86_64.  The reason for that is that
we do the run-time test using cpuid.

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [PATCH] OpenSSL: Mark underlying BIO with the appropriate type flags
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Shared memory size computation oversight?