From patchwork Sat Jun 3 11:25:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xi Ruoyao X-Patchwork-Id: 70559 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 91FD43858CDA for ; Sat, 3 Jun 2023 11:26:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91FD43858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685791586; bh=deg5XD66adgTsKA60zjwy6cM7+TedNrk2WW3qJi9frw=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=ks+IIeYgo/bXdcMaQCqDDkl7vXYAAXYm+n3WD/I4TZZizQXiAv/Irlh4mXvzxBdrB tP8lkRZlUD0i26ll2w9HXA17CLEVEyVer7DZQlgiZNn+ZhNdbZnJPrE/rVfMaxrXh/ lREXSjdTESRs0SANi13ISU2yWqokqYzNwlVqr5jY= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id A3EB63858D32 for ; Sat, 3 Jun 2023 11:25:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A3EB63858D32 Received: from stargazer.. (unknown [IPv6:240e:358:1174:da00:dc73:854d:832e:6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id E1D0D66418; Sat, 3 Jun 2023 07:25:53 -0400 (EDT) To: gcc-patches@gcc.gnu.org Cc: Jakub Jelinek , Xi Ruoyao Subject: [PATCH] libatomic: x86_64: Always try ifunc Date: Sat, 3 Jun 2023 19:25:32 +0800 Message-ID: <20230603112532.3264658-1-xry111@xry111.site> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, LIKELY_SPAM_FROM, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Xi Ruoyao via Gcc-patches From: Xi Ruoyao Reply-To: Xi Ruoyao Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" We used to skip ifunc check when CX16 is available. But now we use CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16 alone is not a sufficient reason not to use ifunc (see PR104688). This causes a subtle and annoying issue: when GCC is built with a higher -march= setting in CFLAGS_FOR_TARGET, ifunc is disabled and the worst (locked) implementation of __atomic_load_16 is always used. There seems no good way to check if the CPU is Intel or AMD from the built-in macros (maybe we can check every known model like __skylake, __bdver2, ..., but it will be very error-prune and require an update whenever we add the support for a new x86 model). The best thing we can do seems "always try ifunc" here. Bootstrapped and tested on x86_64-linux-gnu. Ok for trunk? libatomic/ChangeLog: * configure.tgt: For x86_64, always set try_ifunc=yes. --- libatomic/configure.tgt | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt index a92ae9e8309..39dd5686f2e 100644 --- a/libatomic/configure.tgt +++ b/libatomic/configure.tgt @@ -100,9 +100,7 @@ EOF fi cat > conftestx.c <