Message ID | eec88dfcec8092033aac7c3b30268f437e6ad1ea.1601569371.git.fweimer@redhat.com |
---|---|
State | Dropped |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> 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 E989E398B887; Thu, 1 Oct 2020 16:33:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E989E398B887 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601570034; bh=Cze/LhLguodUKlPt55/auXSxv8mlLg/iAElCXvAlIPs=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=CUCYIdRz3M5v5tYcdny1sROMmO/+3b7vflBQonzwOlmsliulzFY76INu+S6kItuGe sjTQQL37sz4SdA2kf1ckuObfs09dDT/Fv9cDuq96l3oQ22F8HBvvTCHwu8+KTzjDVS rXV7GeQLDQAZkc1YSTndfnK+2kD3WRRjzDMIZ4XM= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 603CD398B887 for <libc-alpha@sourceware.org>; Thu, 1 Oct 2020 16:33:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 603CD398B887 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-372-pBDDBvr3OgqyaFvR17APJg-1; Thu, 01 Oct 2020 12:33:49 -0400 X-MC-Unique: pBDDBvr3OgqyaFvR17APJg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 64470101FFA4 for <libc-alpha@sourceware.org>; Thu, 1 Oct 2020 16:33:48 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-84.ams2.redhat.com [10.36.114.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C0BA57880A for <libc-alpha@sourceware.org>; Thu, 1 Oct 2020 16:33:47 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH 20/28] aarch64: Add glibc-hwcaps support In-Reply-To: <cover.1601569371.git.fweimer@redhat.com> References: <cover.1601569371.git.fweimer@redhat.com> Message-Id: <eec88dfcec8092033aac7c3b30268f437e6ad1ea.1601569371.git.fweimer@redhat.com> Date: Thu, 01 Oct 2020 18:33:45 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Florian Weimer <fweimer@redhat.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
glibc-hwcaps support
|
|
Commit Message
Florian Weimer
Oct. 1, 2020, 4:33 p.m. UTC
At this point, only the "atomics" subdirectory is available, for libraries built using LSE atomics. --- sysdeps/aarch64/dl-hwcaps-subdirs.c | 31 +++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 sysdeps/aarch64/dl-hwcaps-subdirs.c
Comments
On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: > At this point, only the "atomics" subdirectory is available, > for libraries built using LSE atomics. LGTM, thanks. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > --- > sysdeps/aarch64/dl-hwcaps-subdirs.c | 31 +++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > create mode 100644 sysdeps/aarch64/dl-hwcaps-subdirs.c > > diff --git a/sysdeps/aarch64/dl-hwcaps-subdirs.c b/sysdeps/aarch64/dl-hwcaps-subdirs.c > new file mode 100644 > index 0000000000..fd6325024e > --- /dev/null > +++ b/sysdeps/aarch64/dl-hwcaps-subdirs.c > @@ -0,0 +1,31 @@ > +/* Architecture-specific glibc-hwcaps subdirectories. aarch64 version. > + Copyright (C) 2020 Free Software Foundation, Inc. > + This file is part of the GNU C Library. > + > + The GNU C Library is free software; you can redistribute it and/or > + modify it under the terms of the GNU Lesser General Public > + License as published by the Free Software Foundation; either > + version 2.1 of the License, or (at your option) any later version. > + > + The GNU C Library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + Lesser General Public License for more details. > + > + You should have received a copy of the GNU Lesser General Public > + License along with the GNU C Library; if not, see > + <https://www.gnu.org/licenses/>. */ > + > +#include <dl-hwcaps.h> > +#include <ldsodefs.h> > + > +const char _dl_hwcaps_subdirs[] = "atomics"; > + > +int32_t > +_dl_hwcaps_subdirs_active (void) > +{ > + if (GLRO (dl_hwcap) & HWCAP_ATOMICS) > + return 1; > + > + return 0; > +} > Ok.
* Adhemerval Zanella via Libc-alpha: > On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: >> At this point, only the "atomics" subdirectory is available, >> for libraries built using LSE atomics. > > LGTM, thanks. > > Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Thanks. I didn't want to skip AArch64, but it's really more of a stub implementation: >> +const char _dl_hwcaps_subdirs[] = "atomics"; Does this still make sense with GCC defaulting to -moutline-atomics for ARMv8a? That's what I wonder. Eventually, we need to define some levels for AArch64, and I'm not sure to what extent they would align with the official 8.X versions. To me, they look more like a bouquet you can choose from. Thanks, Florian
On 14/10/2020 11:08, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: >>> At this point, only the "atomics" subdirectory is available, >>> for libraries built using LSE atomics. >> >> LGTM, thanks. >> >> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > > Thanks. I didn't want to skip AArch64, but it's really more of a stub > implementation: > >>> +const char _dl_hwcaps_subdirs[] = "atomics"; > > Does this still make sense with GCC defaulting to -moutline-atomics for > ARMv8a? That's what I wonder. > > Eventually, we need to define some levels for AArch64, and I'm not sure > to what extent they would align with the official 8.X versions. To me, > they look more like a bouquet you can choose from. I am not sure how ARM maintainers would like to handle it, either by defining based on ARMv8.x revisions, a subsets of HWCAP capabilities, or by not defining anything. For now I think the atomic makes sense because of -moutline-atomics, although it is essentially ARMv8.1.
The 10/14/2020 11:15, Adhemerval Zanella via Libc-alpha wrote: > On 14/10/2020 11:08, Florian Weimer wrote: > > * Adhemerval Zanella via Libc-alpha: > >> On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: > >>> At this point, only the "atomics" subdirectory is available, > >>> for libraries built using LSE atomics. > >> > >> LGTM, thanks. > >> > >> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > > > > Thanks. I didn't want to skip AArch64, but it's really more of a stub > > implementation: > > > >>> +const char _dl_hwcaps_subdirs[] = "atomics"; > > > > Does this still make sense with GCC defaulting to -moutline-atomics for > > ARMv8a? That's what I wonder. > > > > Eventually, we need to define some levels for AArch64, and I'm not sure > > to what extent they would align with the official 8.X versions. To me, > > they look more like a bouquet you can choose from. > > I am not sure how ARM maintainers would like to handle it, either by > defining based on ARMv8.x revisions, a subsets of HWCAP capabilities, > or by not defining anything. > > For now I think the atomic makes sense because of -moutline-atomics, > although it is essentially ARMv8.1. the atomics path logic was added in glibc 2.28 in commit 397c54c1afa531242602fe3ac7bb47eff0e909f9 (see the reasoning in the commit message). since then this is public api that users may rely on (although likely there are not many users..) so i dont want to remove it (and yes it's not very helpful now that outline-atomics is the default in gcc). otoh i did not review this patch when it was posted because i wanted the return value to not be a signed int when it is a bit mask.
On 14/10/2020 11:37, Szabolcs Nagy wrote: > The 10/14/2020 11:15, Adhemerval Zanella via Libc-alpha wrote: >> On 14/10/2020 11:08, Florian Weimer wrote: >>> * Adhemerval Zanella via Libc-alpha: >>>> On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: >>>>> At this point, only the "atomics" subdirectory is available, >>>>> for libraries built using LSE atomics. >>>> >>>> LGTM, thanks. >>>> >>>> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> >>> >>> Thanks. I didn't want to skip AArch64, but it's really more of a stub >>> implementation: >>> >>>>> +const char _dl_hwcaps_subdirs[] = "atomics"; >>> >>> Does this still make sense with GCC defaulting to -moutline-atomics for >>> ARMv8a? That's what I wonder. >>> >>> Eventually, we need to define some levels for AArch64, and I'm not sure >>> to what extent they would align with the official 8.X versions. To me, >>> they look more like a bouquet you can choose from. >> >> I am not sure how ARM maintainers would like to handle it, either by >> defining based on ARMv8.x revisions, a subsets of HWCAP capabilities, >> or by not defining anything. >> >> For now I think the atomic makes sense because of -moutline-atomics, >> although it is essentially ARMv8.1. > > the atomics path logic was added in glibc 2.28 in > commit 397c54c1afa531242602fe3ac7bb47eff0e909f9 > (see the reasoning in the commit message). > > since then this is public api that users may rely > on (although likely there are not many users..) > > so i dont want to remove it (and yes it's not > very helpful now that outline-atomics is the > default in gcc). > > otoh i did not review this patch when it was > posted because i wanted the return value to > not be a signed int when it is a bit mask. > Ok fair enough, do you plan to send an updated version Florian or the rest of the set is ok as-is to review?
* Szabolcs Nagy: > The 10/14/2020 11:15, Adhemerval Zanella via Libc-alpha wrote: >> On 14/10/2020 11:08, Florian Weimer wrote: >> > * Adhemerval Zanella via Libc-alpha: >> >> On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: >> >>> At this point, only the "atomics" subdirectory is available, >> >>> for libraries built using LSE atomics. >> >> >> >> LGTM, thanks. >> >> >> >> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> >> > >> > Thanks. I didn't want to skip AArch64, but it's really more of a stub >> > implementation: >> > >> >>> +const char _dl_hwcaps_subdirs[] = "atomics"; >> > >> > Does this still make sense with GCC defaulting to -moutline-atomics for >> > ARMv8a? That's what I wonder. >> > >> > Eventually, we need to define some levels for AArch64, and I'm not sure >> > to what extent they would align with the official 8.X versions. To me, >> > they look more like a bouquet you can choose from. >> >> I am not sure how ARM maintainers would like to handle it, either by >> defining based on ARMv8.x revisions, a subsets of HWCAP capabilities, >> or by not defining anything. >> >> For now I think the atomic makes sense because of -moutline-atomics, >> although it is essentially ARMv8.1. > > the atomics path logic was added in glibc 2.28 in > commit 397c54c1afa531242602fe3ac7bb47eff0e909f9 > (see the reasoning in the commit message). > > since then this is public api that users may rely > on (although likely there are not many users..) > > so i dont want to remove it (and yes it's not > very helpful now that outline-atomics is the > default in gcc). This patch adds glibc-hwcaps/atomics as a new subdirectory. The whole series does not remove the legacy directories. Based on what you wrote, I should drop this patch, right? Thanks, Florian
The 10/14/2020 16:44, Florian Weimer wrote: > * Szabolcs Nagy: > > > The 10/14/2020 11:15, Adhemerval Zanella via Libc-alpha wrote: > >> On 14/10/2020 11:08, Florian Weimer wrote: > >> > * Adhemerval Zanella via Libc-alpha: > >> >> On 01/10/2020 13:33, Florian Weimer via Libc-alpha wrote: > >> >>> At this point, only the "atomics" subdirectory is available, > >> >>> for libraries built using LSE atomics. > >> >> > >> >> LGTM, thanks. > >> >> > >> >> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> > >> > > >> > Thanks. I didn't want to skip AArch64, but it's really more of a stub > >> > implementation: > >> > > >> >>> +const char _dl_hwcaps_subdirs[] = "atomics"; > >> > > >> > Does this still make sense with GCC defaulting to -moutline-atomics for > >> > ARMv8a? That's what I wonder. > >> > > >> > Eventually, we need to define some levels for AArch64, and I'm not sure > >> > to what extent they would align with the official 8.X versions. To me, > >> > they look more like a bouquet you can choose from. > >> > >> I am not sure how ARM maintainers would like to handle it, either by > >> defining based on ARMv8.x revisions, a subsets of HWCAP capabilities, > >> or by not defining anything. > >> > >> For now I think the atomic makes sense because of -moutline-atomics, > >> although it is essentially ARMv8.1. > > > > the atomics path logic was added in glibc 2.28 in > > commit 397c54c1afa531242602fe3ac7bb47eff0e909f9 > > (see the reasoning in the commit message). > > > > since then this is public api that users may rely > > on (although likely there are not many users..) > > > > so i dont want to remove it (and yes it's not > > very helpful now that outline-atomics is the > > default in gcc). > > This patch adds glibc-hwcaps/atomics as a new subdirectory. The whole > series does not remove the legacy directories. > > Based on what you wrote, I should drop this patch, right? ah i missed that legacy is handled independently. in that case, yes please drop this.
* Adhemerval Zanella: > Ok fair enough, do you plan to send an updated version Florian > or the rest of the set is ok as-is to review? The rest of the set is ready for review. There were some conflicts with the adjustments based on the comments so far. I have rebased the fw/glibc-hwcaps branch on sourceware to reflect what I currently have locally. Thanks, Florian
diff --git a/sysdeps/aarch64/dl-hwcaps-subdirs.c b/sysdeps/aarch64/dl-hwcaps-subdirs.c new file mode 100644 index 0000000000..fd6325024e --- /dev/null +++ b/sysdeps/aarch64/dl-hwcaps-subdirs.c @@ -0,0 +1,31 @@ +/* Architecture-specific glibc-hwcaps subdirectories. aarch64 version. + Copyright (C) 2020 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <https://www.gnu.org/licenses/>. */ + +#include <dl-hwcaps.h> +#include <ldsodefs.h> + +const char _dl_hwcaps_subdirs[] = "atomics"; + +int32_t +_dl_hwcaps_subdirs_active (void) +{ + if (GLRO (dl_hwcap) & HWCAP_ATOMICS) + return 1; + + return 0; +}