From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A2A8A1F487 for ; Fri, 27 Mar 2020 14:26:06 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 86AD6385E013; Fri, 27 Mar 2020 14:26:05 +0000 (GMT) Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 51C9E385E007 for ; Fri, 27 Mar 2020 14:26:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 51C9E385E007 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jHpvt-0008N9-Cx; Fri, 27 Mar 2020 14:26:01 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jHpvt-0005nP-7X; Fri, 27 Mar 2020 15:26:01 +0100 From: Florian Weimer To: Carlos O'Donell via Libc-alpha Subject: Re: [PATCH 0/3] RFC: Platform Support for AMD Zen and AVX2/AVX References: <20200317044646.29707-1-PMallappa@amd.com> <87wo7je4me.fsf@mid.deneb.enyo.de> <6a5b92f9-31d9-01c6-e6c6-acf1554e4458@redhat.com> <11fbb273-bced-f806-d949-3a3bd2f54818@redhat.com> Date: Fri, 27 Mar 2020 15:26:01 +0100 In-Reply-To: <11fbb273-bced-f806-d949-3a3bd2f54818@redhat.com> (Carlos O'Donell via Libc-alpha's message of "Tue, 17 Mar 2020 17:37:05 -0400") Message-ID: <87ftdtho1y.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * Carlos O'Donell via Libc-alpha: > On 3/17/20 3:27 PM, Adhemerval Zanella via Libc-alpha wrote: >> On 17/03/2020 10:17, Carlos O'Donell via Libc-alpha wrote: >>> Agreed. This is the only sensible plan. The platform directories already >>> imply some of this, but it's not well structured. >> >> Which should be our policy regarding the platform name over releases? >> Should the names set in previous release being supported in a >> compatibility manner or should it not be constraint (as for tunables) >> and subject of change? > > It should be subject to change just like tunables. I disagree; for a subset of the directories, we should guarantee stability. > It should be an optimization, and not a requirement, and applications > should always provide a fallback implementaiton to allow the application > to load. Agreed. Programmers need to assume that future glibc versions may stop selecting certain subdirectories. However, I'm not sure if we can suddenly start selecting directories on systems where we did not do so before. > We should verify that downstream distributions can use /etc/ld.so.conf > as a way to add back directories into the search of the existing > additional multilib search directories e.g. Add back /lib64/haswell > for a few years. I don't think that works. > In the end I think we'll want: > > (a) Try CPU vendor directories first. > - Each vendor should name their directories and the explicit > compiler options to target them (printed by LD_DEBUG). > > (b) Try shared directories second. > - Based on a common set of identified features. > - Compiler options to target the shared set should be explicitly > stated (printed by LD_DEBUG). > > My understanding is that Florian is asking for help with (b) > to identify what things should be enabled for current CPUs, and > that we'll compare that list to the Intel list and make a common > shared directory that the downstream distributions can used > for the most optimized library we can have in common. The results for (b) also feed into (a) to some extent because if research for (b) reveals that certain CPU features have been disabled by microupdate updates, we probably do not want them for (a), either.