From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44324) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8lyl-0004wn-Af for qemu-devel@nongnu.org; Mon, 21 Nov 2016 05:37:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8lyi-0007WC-9I for qemu-devel@nongnu.org; Mon, 21 Nov 2016 05:37:39 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:34176) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c8lyi-0007Vi-1g for qemu-devel@nongnu.org; Mon, 21 Nov 2016 05:37:36 -0500 Received: by mail-wm0-x241.google.com with SMTP id g23so616945wme.1 for ; Mon, 21 Nov 2016 02:37:35 -0800 (PST) Sender: Richard Henderson References: <1479324335-2074-1-git-send-email-rth@twiddle.net> <1479324335-2074-17-git-send-email-rth@twiddle.net> <1e2e6eab-921a-f30b-93d4-66bd62f68dd1@mail.uni-paderborn.de> <0e841b99-5994-120d-bd4f-051b694d1ca4@mail.uni-paderborn.de> <3e699be9-3948-ad3b-d7a9-21a3df91a704@mail.uni-paderborn.de> From: Richard Henderson Message-ID: <5b549d38-82dc-8d42-d264-67d075a8bebe@twiddle.net> Date: Mon, 21 Nov 2016 11:37:28 +0100 MIME-Version: 1.0 In-Reply-To: <3e699be9-3948-ad3b-d7a9-21a3df91a704@mail.uni-paderborn.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 16/25] tcg/i386: Handle ctz and clz opcodes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bastian Koppelmann , qemu-devel@nongnu.org On 11/18/2016 01:48 PM, Bastian Koppelmann wrote: > On 11/18/2016 12:03 AM, Richard Henderson wrote: >> On 11/17/2016 11:09 PM, Bastian Koppelmann wrote: >>> On 11/17/2016 08:59 PM, Richard Henderson wrote: >>>> On 11/17/2016 08:53 PM, Richard Henderson wrote: >>>>> On 11/17/2016 05:50 PM, Bastian Koppelmann wrote: >>>>>> On 11/16/2016 08:25 PM, Richard Henderson wrote: >>>>>>> + >>>>>>> + OP_32_64(clz): >>>>>>> + if (const_args[2]) { >>>>>>> + tcg_debug_assert(have_bmi1); >>>>>>> + tcg_debug_assert(args[2] == (rexw ? 64 : 32)); >>>>>>> + tcg_out_modrm(s, OPC_LZCNT + rexw, args[0], args[1]); >>>>>>> + } else { >>>>>>> + /* ??? See above. */ >>>>>>> + tcg_out_modrm(s, OPC_BSR + rexw, args[0], args[1]); >>>>>> >>>>>> The Intel ISA manual states that it find the bit index of the most >>>>>> significant bit, where the least significant bit is index 0. So for >>>>>> the >>>>>> input 0x2 this should return 1. However this is not the number of >>>>>> leading zeros. >>>>> >>>>> Oh, of course you're right. I thought I was testing this, but while >>>>> alpha does >>>>> have this operation, it turns out it isn't used much. >>>> >>>> Alternately, what I tested was on a haswell machine, which takes the >>>> LZCNT path, which *does* produce the intended results. Just the BSR >>>> path doesn't. >>> >>> Luckily my old laptop is a Core 2 Duo without LZCNT :) >> >> Heh. Well, I've given it another few tests with LZCNT hacked off, and >> with i686 32-bit. Here's an incremental update. Wherein I also note >> that lzcnt isn't in the same cpuid flag as tzcnt. Double whoops. > > My processor[1] seems to lie about the LZCNT cpuid flag. It says it has > LZCNT but executes it as BSR. According to [2] ABM flag is used to > indicate LZCNT support. Yes, the gcc cpuid.h comment for the lzcnt bit, i.e. to which leaf it should apply, is wrong. I'll get that fixed in the next revision. r~