From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 4452D383568B for ; Fri, 22 Jul 2022 08:12:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4452D383568B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 093C033D74; Fri, 22 Jul 2022 08:12:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1658477532; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zr9ZUIkQvsPDVUJLJZRvWdNHdrXFP16KJqT17l+Q3VU=; b=Jj2z3nzytz72k73WGNSYE+brbrev6WoTtJnxBF3wg0ylKuHR47CsqzB0TI1hH4L/QnjeHo GYwTC7DOUie4RZwARl3nXYFnMsY5u1ksdhtwL9/9StwhzDP+Ve7csHUNUUjxCo4zazAtTe LTZC9Ih6n68jiA1vlZCSqCC4ueBH57s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1658477532; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zr9ZUIkQvsPDVUJLJZRvWdNHdrXFP16KJqT17l+Q3VU=; b=7EJqUOlLKJ2PGrRQbOTWDwhAt4N87jZrLtZTXtr9l7cuaIulI6MwCtSmjKXfVVxSMab/pS gCBPv4HocHRiuiDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C7A9D13AB3; Fri, 22 Jul 2022 08:12:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id zsYZK9tb2mLDQgAAMHmgww (envelope-from ); Fri, 22 Jul 2022 08:12:11 +0000 Message-ID: Date: Fri, 22 Jul 2022 10:12:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC] Function Multi Versioning on Arm Content-Language: en-US To: Daniel Kiss Cc: "gcc@gcc.gnu.org" , Pavel Iliin References: <45073915-9D33-4097-9CFD-FFBCB9CE1A44@arm.com> <285FC35B-89C4-405B-AA87-21E838B58F60@arm.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= In-Reply-To: <285FC35B-89C4-405B-AA87-21E838B58F60@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2022 08:12:19 -0000 On 7/21/22 19:49, Daniel Kiss wrote: > Hello, > > Thanks for the quick reply, see mine inline. >> On 2022. Jul 19., at 12:01, Martin Liška wrote: >> >> On 7/18/22 12:36, Daniel Kiss via Gcc wrote: >>> Hello, >>> >>> We are going to add Function Multiversioning [1] support to Arm architectures. >>> The specification is made public as beta[2] to ensure toolchain that follows Arm >>> C Language Extension will implement it in the same way. >>> >>> A few tweaks considered to make the developers' life easier. >>> Since the `target` attribute is used widely on Arm, we would like to introduce a >>> new attribute `target_version` to avoid confusion and possible deployment >>> problems. The `target_clones` attribute will be supported too. Also the “default” >>> version to be made optional. >>> >>> We are looking for feedback on the specification (reply, github works too). >>> >>> Thanks so much, >>> Daniel >>> >>> [1] https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html >>> [2] https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning >>> >> >> Hello. >> >> Thanks for working on the feature, it will be nice to cover the gap in between x86_64 and powerpc, >> which implement the FMV feature. >> >> As the person who's been involved with the current MVC code in the GCC, I have a few comments/questions >> about it: >> >> 1) both i386 and Powerpc also allow specifying an equivalent to -march (like `arch=bdver2`), >> in Arm case it seems to me only individual features are considered > Arm architecture version is not definite enough in this case because > certain features are optional on a given versions and may back ported to older versions. > Implementation name of a core also could be misleading in most of the cases. And too many out there if > all implementation is considered not just Arm’s Cortex cores. > Also the kernel support varies regardless the actual hardware, features can be disabled by the firmware/OS. > I think developers target a given feature instead of a given uarch most cases. Sure, that makes fully sense to me! > >> >> 2) about 'target_version' attribute - I like the idea as one can have a completely independent >> function implementation optimized for an ISA; >> note it's very close to 'target' attribute (supported in C++), where one needs to provide >> a resolver and have the pretty same functionality (see e.g. gcc/testsuite/g++.target/i386/mv1.C). >> However, the feature does not work in C and you will have the very same problem with target_version >> attribute (multiple functions with the same declaration): >> >> mv1.c:76:1: error: redefinition of ‘foo’ >> 76 | foo () >> | ^~~ > In our clang implementation\prototype such a use case is supported. The goal was to able to write like this in C > /* existing code*/ > extern int foo(); > int foo(){} > /* addition */ > #ifdef __ARM_FEATURE_FUNCTION_MULTI_VERSIONING > __attribute__((target_version(“..."))) > int foo(){} > #endif I see, so then it's going to require a more work regarding the C front-end. Maybe we should enable the same way the "target" attribute for C. > > so an existing codebase can be extended without breaking it even for old compilers, without heavy checks for attribute support. Yep. > >> 3) If you will implement 'target_version' attribute, I would like to see it available also for the >> existing targets supporting MVC > Yes, this is the plan if other target maintainers will accept it. > IMHO all semantical differences would work for all targets. Sure! >> >> 4) A small note about the mangling, the existing i386 naming scheme looks like: >> >> ... >> _Z3foov.avx2_ssse3 >> ... >> >> 5) Can you please define how will you evaluate priorities for a situation where multiple features >> are used (e.g. dotprod+sm)? >> >> Note we face the very same problem on i386, where it's very hard to specify a priority >> for the family of avx512 features. That said, an optional priority specifier might be possible. > ACLE provides a table of priorities for given feature and a simple algorithm how to choose. > > Version where the most features are requested will be picked, Ok! > then the one with the highest priority. > in case of (dotprod+sm, sve) set the dotprod+sm will be selected just because it is more specified, even > sve has higher priority. > > We considered the other of the attributes in the source, but that might be quite problematic to preserve during > compilation. We can start with that and add priorities later if really needed. > > A new attribute or variant that provides priority could work too, just so far the newer feature usually a better > choice, and those got higher priority. > >> >> 6) Note that as opposed to i385 and Powerpc, we don't allow a combination of ISA flags for target_clone >> attribute (like sse2+avx512f). > Noted, I think in case of Arm it may make sense to support it. >> >> 7) FMV may be disabled in compile time by a compiler flag. In this case the default version shall be used. >> >> I would like to see the functionality also target agnostic. > Sure, I agree. the proposed flag is -mno-fmv (-mfmv default on). > Also maybe the feature indication define __ARM_FEATURE_FUNCTION_MULTI_VERSIONING could be just > __FEATURE_FUNCTION_MULTI_VERSIONING? I would take a name inspiration from: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html so what about something like __HAVE_FUNCTION_MULTI_VERSIONING ? Cheers, Martin > >> >> Anyway, looking forward to the Arm implementation. >> Hope the comments are constructive. > Thanks, help me a lot. > >> >> Cheers, >> Martin >