| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
| Subject: | Re: call popcount32/64 directly on non-x86 platforms |
| Date: | 2021-08-12 14:01:14 |
| Message-ID: | CAFBsxsFAgUmgSoq-wdPQdnxwvauHjRYvbvqTmku+KShAko11dQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 12, 2021 at 9:33 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> 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.
Yeah, it's a bit strange, a configure check makes more sense if we have a
way to specify we can build with a direct call (like x86-64-v2), but we
don't right now. Maybe short-term we could always do the runtime check on
x86-64.
--
John Naylor
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2021-08-12 14:18:47 | Re: Shared memory size computation oversight? |
| Previous Message | Peter Eisentraut | 2021-08-12 13:34:27 | Re: Shared memory size computation oversight? |