From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Thomas Munro <thomas.munro@enterprisedb.com>,
        Andrew Gierth <andrew@tao11.riddles.org.uk>,
        David Rowley <david.rowley@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Using POPCNT and other advanced bit manipulation instructions
In-reply-to: <20190214184713.GA6080@alvherre.pgsql>
References: <20190214184713.GA6080@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 14 Feb 2019 15:47:13 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25933.1550170472.1@sss.pgh.pa.us>
Date: Thu, 14 Feb 2019 13:54:32 -0500
Message-ID: <25934.1550170472@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 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

> to
> 	lzcntq	%rax, %rax

> Significant?

I'd bet a fair amount of money that we'd be better off *not* using
lzcnt, even if available, because then we could just expose things
along this line:

static inline int
pg_clz(...)
{
#ifdef HAVE__BUILTIN_CLZ
    return __builtin_clz(x);
#else
    handwritten implementation;
#endif
}

Avoiding a function call (that has to indirect through a pointer) probably
saves much more than the difference between lzcnt and the other way.

The tradeoff might be different for popcount, though, especially since
it looks like __builtin_popcount() is not nearly as widely available
as the clz/ctz builtins.

			regards, tom lane