Message ID | 20230603112532.3264658-1-xry111@xry111.site |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp1600015vqr; Sat, 3 Jun 2023 04:26:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5o0KMHHf0PWx3psngzhhSGBZ1ebiQb4KNYGsgiabXDWpx2zTZlf9nYZE90VSEIWhPAnYby X-Received: by 2002:a17:907:6288:b0:94f:3521:396 with SMTP id nd8-20020a170907628800b0094f35210396mr1140491ejc.23.1685791603090; Sat, 03 Jun 2023 04:26:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685791603; cv=none; d=google.com; s=arc-20160816; b=dDeispkpk4RRuvDX1H+64TT8Ai2iu33sjKkAC0M2dYBlKtlMUt5KWN8KOrK3zNZ0WC VAqtibWfq5htSIt9kYp9cIfE/eyBva7je49KyuVAPUZx73d6XjjahcKgtQJ0R0QsS+Mv 5ayywW926qjxdCMRq+L9q78340DBBwxx/FU3UT0rkS61bJf4RiF18HWPzMU/7dX5hAaF 4u6OFtNSespMOJgGDu/sJIFDwolBUfnCspZwR1beI2MGfPJKE7fA1Lh6SJmPHoS1VF0o tcF3oZsf3cyLcLWn/kDYmwlzT0z+7x0gsTglac33VPlZDC4Mtu3MsLfzRGn/pV6foR9h ldZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:cc :to:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=deg5XD66adgTsKA60zjwy6cM7+TedNrk2WW3qJi9frw=; b=GUmDv41rvPiJV8Pc3fSrb9Kmi5aFZAft33fOQ+vMfyrBOUG1n1u723wSJpI4+mxOlG c4mtkUywcZOESwTZzLND6FkQqDTtnnqnTWNXbqgYPBx+uWMKgoK8XGlH/cGi1mC4PSly DjX7QiNslAjOoqWL6xR4f4eAjEtaVZje5/TnxRri/o6B4Xy1Rs+cynehMg/XIKTXy/Cr DA6evNqU7ooSbz9HVJxF8IU6A9zpDpktWLY9n66NMfQIzVoloFjKtpU3TYUJCvB7AY3x uBokRvVOVgaorEJvLSwf9v4tCAyONueItDZU3HBO/bA95KGNS6QzbKXp0LTcROXKaryT KqqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=NYalOzto; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id v5-20020a170906180500b009745cd42b5dsi2344405eje.861.2023.06.03.04.26.42 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Jun 2023 04:26:43 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=NYalOzto; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 09EC73858C33 for <ouuuleilei@gmail.com>; Sat, 3 Jun 2023 11:26:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 09EC73858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685791602; 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=NYalOzto/qVckG5rBSO712URyP+g8w7HQI/rUE3/W7L8bDRl8VzVhgTtcL8Qu5jcs sKCO/w8HMyYV7eGHl8/f3QSxDlxMtl+R8dk/TwGL3h/UMS5U7stBXUwNcJzmSalxCb tjfUouY63aVMegYqPDyel8kuCq4k+XHej44I5ZZA= 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 <gcc-patches@gcc.gnu.org>; 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 <jakub@redhat.com>, Xi Ruoyao <xry111@xry111.site> 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 Content-Transfer-Encoding: 8bit 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Xi Ruoyao <xry111@xry111.site> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767680615967975859?= X-GMAIL-MSGID: =?utf-8?q?1767680615967975859?= |
Series |
libatomic: x86_64: Always try ifunc
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Xi Ruoyao
June 3, 2023, 11:25 a.m. UTC
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(-)
Comments
On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >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. IIRC there is __builtin_cpu_is (after initialisation) -- A couple of days ago, we wondered if it would be handy to lower that even in fortran without going through C, so i am pretty sure I don't make that up.. ;-) Just a thought,
On Sat, 2023-06-03 at 14:53 +0200, Bernhard Reutner-Fischer wrote: > On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > 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. > > IIRC there is __builtin_cpu_is (after initialisation) -- A couple of > days ago, we wondered if it would be handy to lower that even in > fortran without going through C, so i am pretty sure I don't make that > up.. ;-) Unfortunately __builtin_cpu_is performs CPU detection on runtime, not compile time.
On 3 June 2023 15:46:02 CEST, Xi Ruoyao <xry111@xry111.site> wrote: >Unfortunately __builtin_cpu_is performs CPU detection on runtime, not >compile time. Right, you were talking about configure, sorry.
Ping (in hopes that someone can review before the weekend). On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote: > 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 <<EOF > #ifdef __x86_64__ > -#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 > -#error need -mcx16 > -#endif > +#error ifunc is always wanted for 16B atomic load > #else > #ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 > #error need -march=i686
On Fri, Jun 09, 2023 at 08:37:20PM +0800, Xi Ruoyao wrote: > Ping (in hopes that someone can review before the weekend). > > On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote: > > 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. Ok, thanks. Jakub
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 <<EOF #ifdef __x86_64__ -#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 -#error need -mcx16 -#endif +#error ifunc is always wanted for 16B atomic load #else #ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 #error need -march=i686