| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Using POPCNT and other advanced bit manipulation instructions |
| Date: | 2019-02-14 21:45:38 |
| Message-ID: | 822.1550180738@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-02-14 15:47:13 -0300, Alvaro Herrera wrote:
>> Hah, I just realized you have to add -mlzcnt in order for these builtins
>> to use the lzcnt instructions. It goes from something like
>>
>> bsrq %rax, %rax
>> xorq $63, %rax
> I'm confused how this is a general count leading zero operation? Did you
> use constants or something that allowed ot infer a range in the test? If
> so the compiler probably did some optimizations allowing it to do the
> above.
No. If you compile
int myclz(unsigned long long x)
{
return __builtin_clzll(x);
}
at -O2, on just about any x86_64 gcc, you will get
myclz:
.LFB1:
.cfi_startproc
bsrq %rdi, %rax
xorq $63, %rax
ret
.cfi_endproc
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2019-02-14 21:51:40 | Re: libpq host/hostaddr/conninfo inconsistencies |
| Previous Message | legrand legrand | 2019-02-14 21:21:39 | Re: Planning counters in pg_stat_statements (using pgss_store) |