Date: Fri, 15 Feb 2019 11:41:23 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, thomas.munro@enterprisedb.com,
	andrew@tao11.riddles.org.uk, david.rowley@2ndquadrant.com,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Using POPCNT and other advanced bit manipulation instructions
Message-ID: <20190215144123.GA31671@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190215142842.GA29812@alvherre.pgsql>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2019-Feb-15, Alvaro Herrera wrote:

> On 2019-Feb-15, Kyotaro HORIGUCHI wrote:

> > And even worse lzcntx is accidentially "fallback"s to bsrx on
> > unsupported CPUs, which leads to bogus results.
> > __builtin_clzll(8) = 3, which should be 60.
> 
> I'm not sure I understand this point.  Are you saying that if we use
> -mlzcnt to compile, then the compiler builtin is broken in platforms
> that don't support the lzcnt instruction?  That's horrible.  Let's stay
> away from -mlzcnt then.

Ah, I understand it now:
https://stackoverflow.com/questions/25683690/confusion-about-bsr-and-lzcnt/43443701#43443701
if you call LZCNT/TZCNT on a CPU that doesn't support it, it won't raise
SIGILL or anything ... it'll just silently compute the wrong result.
That's certainly not what I call a fallback!

I think David's code was correct because it was testing CPUID for
instruction support before using the specialized code (well, except that
he forgot to add the right compiler option to *enable* the LZCNT/TZCNT
instructions in the first place); but given subsequent discussion that
the instruction is not worth it anyway, we might as well ignore it.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services