From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fout2-smtp.messagingengine.com (fout2-smtp.messagingengine.com [103.168.172.145]) by sourceware.org (Postfix) with ESMTPS id 3587D385840D for ; Wed, 24 Apr 2024 14:43:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3587D385840D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3587D385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=103.168.172.145 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713969826; cv=none; b=nEJBHvqnp/bpuOXMWFdj1Ysg04rpOHQg+J7vs/9GiqlZ4lkunwPSlSPVln2g73ANoqPJ5ED6u7x7Tz03aNR9II/O/BQDNI51ibNRvRypwzsEB+cCcZgzccwhDaj76Fuv5e8sKVII25vBE/PcTTTyGU0kLWJb6SMq7il6ZwM8B8Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713969826; c=relaxed/simple; bh=y0DcFUQc9yWf6nud9Lj/dp3JjcEDd52ERmm3XTUUDn4=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Date:Message-Id: Subject:From:To; b=QOK9mXFaLZIL2qrgfwixSdzxuLiHZuF4aO8chR7x5c2rHcfU+o396n2s5SUQpIP5/W5twB0JOHkhAZsl53ffjEvqZNW4mE6wjzl26rBbj/mvlKMoO3efMT+CfLqPqwe8NIRNSQFsJy/Im6pVSc9JcgNln8b6dqLc3vOVceRyqsw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id 062251380140; Wed, 24 Apr 2024 10:43:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 24 Apr 2024 10:43:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1713969825; x=1714056225; bh=HstHCYnD8SgYeBCZI9Gpi8kK1YO3AiYALiMfO0dE20Y=; b= TSzzkMraVKsANDN2M7sRyW7nHB5RAOMYC7hLj7deZivU5mcCniup6F29T6pLvy7a X5bcftQDcDnx25DirqhqJ4RGmX8ZyBp/Qn9XXzZ3naWIxtgW4BjQx5xb4x5SmYmk dcqZQIhFQ/54KlfM34kGmeQKF5bCURcvhoR3bbbcWpXP3gfGquKmQ2rM02SMxJDP Dux95L2R1SnX8h1Hr8LXqYP8EGu6qVs5XeU3s+DySKekei+W579BhuUz60gsMCbl 3w+OMTS8tBOLuPVUzuc7Gvr84v/eSnVnIpZEd+FQE6CCJwuwXfDMN+jJPsLTl1dl gXCj/3KYdKw/FYMom0grkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1713969825; x= 1714056225; bh=HstHCYnD8SgYeBCZI9Gpi8kK1YO3AiYALiMfO0dE20Y=; b=L DSh1C3BGvvEHJn0tz2i+eix9yFnC/uf2SUE4rEwEUviYK4CwQcXO3BrNN1nBSjN8 bfyY4kRF1VjbaxxB2rP1HJluM09kEZltYxk/JHcBltsNmgX++fFldFFMiOAwqvcm yxoj3iwOs+s7k07sKAeNh3+jkgB6aTUkcZB1NDHNyw5UrfbEbaeYbGiePkiM8bFA 7EZT6aHfrjHTkZzwfN1pnSei3sjCPyjBtqlTI6h9+VnoDnMwnb2WyJ/U3ln+ttMo jyBaZX7mF1rMwGGKn7Dzyx4ZHw0NIMWXNkjM7bJj0pcwHz+qdR4pOZM12/oBbEYL wq+1RJexkaHGMkT56HHWQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudelhedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepggfgtgffkffuhffvofhfjgesthhqredtredtjeenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpeekjeetueffheevveeglefgheffgfeikeefgfefleevkeeigeeifeeg jeelueeuvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Apr 2024 10:43:44 -0400 (EDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 24 Apr 2024 10:43:44 -0400 Message-Id: Subject: Re: Maybe we should get rid of ifuncs From: "Zack Weinberg" To: "Richard Henderson" , X-Mailer: aerc 0.16.0 References: In-Reply-To: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue Apr 23, 2024 at 9:41 PM EDT, Richard Henderson wrote: > On 4/23/24 11:14, Zack Weinberg wrote: > > (2) Are there existing ifuncs that perform CPU-capability-based > > function selection that*could not* be replaced with an array of bit > > vectors like what I sketched in the previous paragraph? > > How much is in actual use, I have no idea. However: > Even x86 cpuid generates a staggeringly large bit vector. Oof, yeah. sizeof(struct cpu_features) =3D=3D 488 on x86_64, and over half of that is cpuid dumps. It probably _could_ be compacted, but as Florian pointed out any compaction we implement means glibc has to be updated for new CPU features (but then again we have to do that _anyway_...) Another thing that looking at cpu_features makes obvious is that several architectures include numbers that can't easily be reduced to one-hot representation. It'd be reasonable to want to dispatch on cache line size, for instance. I don't like the idea of embedding something even vaguely resembling a bytecode interpreter in ld.so, and yet... I'm very curious what the plan for function multiversioning in GCC and LLVM is, and how close to declarative it gets. zw