From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 920A93857031 for ; Mon, 13 Jul 2020 13:53:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 920A93857031 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-477-vZYjzg7BM9OlpjwftHU0Hg-1; Mon, 13 Jul 2020 09:53:39 -0400 X-MC-Unique: vZYjzg7BM9OlpjwftHU0Hg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 328B8E8EA0; Mon, 13 Jul 2020 13:53:36 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-218.ams2.redhat.com [10.36.112.218]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 537D15D9CC; Mon, 13 Jul 2020 13:53:35 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 06DDrVmE006556; Mon, 13 Jul 2020 15:53:31 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 06DDrSg9006555; Mon, 13 Jul 2020 15:53:28 +0200 Date: Mon, 13 Jul 2020 15:53:27 +0200 From: Jakub Jelinek To: "H.J. Lu" Cc: Jan Beulich , Florian Weimer , GCC Development , GNU C Library , Tom Stellard , "Mallappa, Premachandra" , x86-64-abi , llvm-dev@lists.llvm.org Subject: Re: New x86-64 micro-architecture levels Message-ID: <20200713135327.GK2363@tucnak> Reply-To: Jakub Jelinek References: <87365zz3a6.fsf@oldenburg2.str.redhat.com> <87pn8zuaky.fsf@oldenburg2.str.redhat.com> <00b82e0f-ba85-f8ec-23b0-5696b31c1b61@suse.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 13:53:44 -0000 On Mon, Jul 13, 2020 at 06:31:31AM -0700, H.J. Lu via Gcc wrote: > > > H.J. has patches for ELF program properties. I think > > > GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information. This > > > proposal and the glibc patches are independent of that. > > > > From (partly just halfway) recent discussions with H.J. I gained > > the understanding that the piece we're aiming at getting to work > > properly is the recording of GNU_PROPERTY_X86_FEATURE_2_*, not > > so much GNU_PROPERTY_X86_ISA_1_*. If the ISA one is to be used as > > a basis here, a lot of new flags will need adding (and properly > > setting) first, I think. > > > > We can update GNU_PROPERTY_X86_ISA_1_* as needed. I am not really sure such properties are a good idea, it will be a maintainability nightmare (as it is on other OSes like Solaris). Think about function multiversioning, target attribute for just some functions, #pragma omp declare simd. How do you differentiate between using those on carefully written code that handles cpuid detection itself or uses compiler support for that, where we do not want to mark the objects in any way, they should work just fine even on K8, and cases where users want something like that? E.g. look for -mclear-hwcap stuff needed for Solaris because of that. Jakub