From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by sourceware.org (Postfix) with ESMTPS id 8E671385840D for ; Wed, 24 Apr 2024 15:09:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E671385840D Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8E671385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f31 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713971393; cv=none; b=xxOZL3002OBw8N4uWgoHNbvNsRppcY9XZ1Vzy8aU++h/BfR3Nfiyljs1jWHd8+Nv3IgeWVAKhpQ8CNy3yE/rLuZzu6usnvIDP2NCKWQYF672Fl3uU8lFu9XhoGBKEt5yTaAQBkpxey640b9dpTy0ikTcfwbh32gi9M0A8vlwpvY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713971393; c=relaxed/simple; bh=vAA3WYBV+pav+LqLr99fYSK+oS42CKHje0TIoXH3TiQ=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=I4M518XyyKoBabpftk+piC04GNXAk290b3Lpr/KG+1+wftNYu/KjDk6UpHA1QqHSwWuvDgXZIPd6NCUeeqJ6G/9Gy1AgDdHXoTc4rQCMJpcYQ/j82SIduxxDEy4qIuvtwx0nDCtoSQN5GUX+6NZENfSgtNO8Ty0ZeePxZN9aPcc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf31.google.com with SMTP id 6a1803df08f44-6a0406438b5so34086d6.1 for ; Wed, 24 Apr 2024 08:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713971382; x=1714576182; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+CElblYQefSdS0JYsthvwCLWRy07uF7ly1x3cPSAQeQ=; b=rHvX78x1MkDH+mmi6gvp3nrP0+p8njkv+TovpLxem8bVj7T1+P+VHR6/gylVr3+bbY wx9W77QDnPNqWFx20CNWBjDA0Nqa4t/iYGofYXavbDn88vndASsxgIQWhMyBjhR9RN6e /iPxijVuZd866rdIINPImREQZzI7zuZ1wABF0CVMESPJERLccneBlrTK494qPaDE6RiZ HgFpLnf2c01SiFoHqV6SOkO73MYJq9GaWINYvMMTkXRG3x1DEd1tFFlP2ha033EnSIpX fi9Yyqd2kVuQ5x//J/3q9ELhAupTpRtJ+vUMt2VFHXxVMFPHwyrpT/6VSG9SDZp/pkZe yFMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713971382; x=1714576182; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+CElblYQefSdS0JYsthvwCLWRy07uF7ly1x3cPSAQeQ=; b=YTcrgq9FVbA08Y74yuNyJqj+TLeugKdXw+jXQpD9DMArbZA3YiN7RVXxHLqbaRL9AV 7wfuizxbOdxlowrbMEFOg/iS3oCHLQ0UiAZYyPX1rSgMEYHNaq+wqBG3hBmb2ekCvlGQ SULLsNqUICMN2j03fY1p1K4+kO/3sbIS2KMhmRoyNofH9T5kel+CtQ1J2CfUhw8eh7Il i1qX9f5oUc5zLMdgIGXZg7STc5QANl/Fs42XdniCEHJLZHI/ipGfJoaFNnD8zrLubKza X4kJMN+ye3meO9AblqNDhRhy/J11dD+4eYJ9eEt5MANyJjy+YJ6INpnnbDp1Wj2m1Nuj YeTA== X-Forwarded-Encrypted: i=1; AJvYcCWAVD4yzM3EnTQ97APzcpnue07b/8Rj7va6NXTxGyOnvjiqxwXOHSgvIhszd+qCT5YKj/UrmPEMQClFo6sPNFPe91Bi8VWJmTD7 X-Gm-Message-State: AOJu0YzWxykhGf91V7UPPwrdNnpOx9Y86vhfuw2JBXB1gIbVwu99MPZp IhFHjkRyar+iFhW0LwWpd/PEODIgm6FRY/xG9tEI6Y396p1GWGJohUcVu9k7bIJqki+DEFKVS+H fRn+EOiGGlDLM0XR6MAqJhjX8h7w2OMmH8k23nMnDMhX+7XQ3NNCm+x8= X-Google-Smtp-Source: AGHT+IHMh/16qZquFZSCfkY/sytKYQDqKMLqVUF/d2jzFrySbvAlHXTl1EEgnk9eNss13OezCk5DXotAR8aPlPk4xWY= X-Received: by 2002:a0c:ef8a:0:b0:69b:2aa8:dc5d with SMTP id w10-20020a0cef8a000000b0069b2aa8dc5dmr2316090qvr.64.1713971381696; Wed, 24 Apr 2024 08:09:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: enh Date: Wed, 24 Apr 2024 08:09:24 -0700 Message-ID: Subject: Re: Maybe we should get rid of ifuncs To: Zack Weinberg Cc: Richard Henderson , libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.7 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Wed, Apr 24, 2024 at 7:43=E2=80=AFAM Zack Weinberg w= rote: > > 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. https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-= versioning is the arm64 spec. the generated code is basically an ifunc resolver that does "if ((hwcap & ... ) && (hwcap2 & ...))". you can see the basic idea in https://reviews.llvm.org/D155026. > zw