From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01E0C33EA for ; Sun, 27 Apr 2025 00:03:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745712202; cv=none; b=oKLYqa/B37K6rz0KNzaMowtDqhJ495p+UzzFr2+4kiA3X1mLACgf0KnOzx6t9bCxMoRQ7pQZV7GnY1XLkJjzumfN6lVt39WvqeyXFWWqls+nXei2WQ7/SP80hqKjCmmzpXMiu7nS9xuyZXjJt+yvb7Mp5PGg9Xxn+ayYoj1Vcvk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745712202; c=relaxed/simple; bh=3SfQbIv4OvLq6P21nmEpbcGExFkyFSCw89XsCc7aY2Y=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=dzA3nbggHUwN8gqC24TzbXiR6X32UhYhvqT/zzqm3OU8ND9SJ89btJ+OFng2IJPe14Mjf+yhjSkyQjKy0qPDW30m7X+nmgu5MU7SkKa90ftJ5+auDZjRfnBTWRcJL9ELcxCaozJxheDRTBowmFCAdZX1wf4JbVmmIb4KzQTc2SQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=GUyFr7K2; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="GUyFr7K2" Received: from [127.0.0.1] ([76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 53R02fAD1021270 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 26 Apr 2025 17:02:41 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 53R02fAD1021270 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025042001; t=1745712163; bh=jlk0WySUzgwBSqt89FwWE6HuFZFIM3PirCQAzgIEfcA=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=GUyFr7K2Ifwtz4UyT6aZbS1skxkjefr619W1KEmSvlIYIusEr8s2C5D/56D1S/gaj 5TIg5JaG2cI23TADG/Bsd+kXCKGboPeBrpMjXmOtBC0A/41RaH+c8Dp5bjiIZT9zr7 4JGSVevyBY0e+wYSYf2+bharQF9IOMt9JRGOYXsi1GFL+LCkjoNrZwcocIy66HQz37 9qZ8STeOk05F+fX/1GmMUejEYb4soCu0SkgLOdQRJe2GhWq+ZTPfr9xuib8WfJZRWv lod+D8/4hNBdCeO1yair463GuclnA5ooNhp2eVTr2xpsX1fF40aHLA7M92L4ghUwlQ bYOdRku2zWt7Q== Date: Sat, 26 Apr 2025 17:02:41 -0700 From: "H. Peter Anvin" To: Linus Torvalds , Arnd Bergmann CC: Ingo Molnar , Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Boris Ostrovsky , Alexander Usyskin , Greg Kroah-Hartman , =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , Mike Rapoport , Ard Biesheuvel , Peter Zijlstra , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH] [RFC] x86/cpu: rework instruction set selection User-Agent: K-9 Mail for Android In-Reply-To: References: <20250425141740.734030-1-arnd@kernel.org> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On April 26, 2025 12:55:13 PM PDT, Linus Torvalds wrote: >On Sat, 26 Apr 2025 at 12:24, Linus Torvalds > wrote: >> >> (And yes, one use in a x86 header file that is pretty questionable >> too: I think the reason for the cmov is actually i486-only behavior >> and we could probably unify the 32-bit and 64-bit implementation) > >Actually, what we *should* do is to remove that manual use of 'cmov' >entirely - even if we decide that yes, that undefined zero case is >actually real=2E > >We should probably change it to use CC_SET(), and the compiler will do >a much better job - and probably never use cmov anyway=2E > >And yes, that will generate worse code if you have an old compiler >that doesn't do ASM_FLAG_OUTPUTS, but hey, that's true in general=2E If >you want good code, you need a good compiler=2E > >And clang needs to learn the CC_SET() pattern anyway=2E > >So I think that manual cmov pattern for x86-32 should be replaced with > > bool zero; > > asm("bsfl %[in],%[out]" > CC_SET(z) > : CC_OUT(z) (zero), > [out]"=3Dr" (r) > : [in] "rm" (x)); > > return zero ? 0 : r+1; > >instead (that's ffs(), and fls() would need the same thing except with >bsrl insteadm, of course)=2E > >I bet that would actually improve code generation=2E > >And I also bet it doesn't actually matter, of course=2E > > Linus It is unfortunate, if understandable, that we ended up using a convention = other than what ended up becoming standard=2E (Return the size in bits if t= he input is 0=2E) This would let us use __builtin_ctz() > tzcnt which I believe is always in= line on x86, and probably would help several other architectures too=2E How much of a pain would it really be to fix this interface?