From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62849 invoked by alias); 17 Aug 2016 09:57:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 62832 invoked by uid 89); 17 Aug 2016 09:56:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:2359, involving, Preud'homme, mfpu X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Aug 2016 09:56:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9A0A52F; Wed, 17 Aug 2016 02:58:21 -0700 (PDT) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 48E813F215; Wed, 17 Aug 2016 02:56:47 -0700 (PDT) Subject: Re: [PATCH, ARM, ping] Use a MULTILIB_REQUIRED approach for aprofile multilib To: kyrylo.tkachov@arm.com, ramana.radhakrishnan@arm.com, richard.earnshaw@arm.com, gcc-patches@gcc.gnu.org References: <7a028fc9-af84-5214-5eb3-87d87f29dd49@foss.arm.com> From: Thomas Preudhomme Message-ID: <13607329-35c4-666c-4f56-a9c949d07bd3@foss.arm.com> Date: Wed, 17 Aug 2016 09:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7a028fc9-af84-5214-5eb3-87d87f29dd49@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01251.txt.bz2 Ping? Best regards, Thomas On 10/08/16 14:51, Thomas Preudhomme wrote: > Hi, > > Currently, the Makefile fragment for ARM aprofile multilib is using a > substractive approach. It specifies a set of options to be combined (eg. > -march=armv7-a,armv7ve,armv8-a, with > -mfpu=vfpv3-d16,neon,vfpv4-d16,neon-fpv4,neon-fp-armv8) using MULTILIB_OPTIONS > and then specifies which combination should *not* be built with > MULTILIB_EXCEPTIONS. > > This patch replaces that approach by an additive one: using MULTILIB_REQUIRED to > specify the combinations we *do* want. This approach is more scalable and > maintainable: > > 1) Scalability > > The substractive approach (MULTILIB_EXCEPTIONS) is doable today because there is > only 3 -march and 5 -mfpu options in t-aprofile. Yet it needs already 22 > MULTILIB_EXCEPTIONS to define the set of multilib to be built. Adding new > architecture or new mfpu would make that worse. Since we only care about a small > number of combinations (each mfpu is used with only one march), it makes more > sense to specify what we want. The new approach only needs 9 MULTILIB_REQUIRED > lines. > > 2) Maintainability > > Adding one new architecture or vfp option means adding exceptions for all > combinations which does not make sense with that option (eg. if we add mfpu=foo > we'll have to exclude all the march we don't want to mix with foo). It forces us > to think about all combinations involved with this new option and thinking about > the combinations in it that we do not want. Basically we have to do the work of > genmultilib in our mind. MULTILIB_REQUIRED on the other hand would allow us to > just specify the combination involving that new option that we care about which > is likely to be more obvious IMHO. > > Patch is in attachment. ChangeLog entry is as follows: > > > *** gcc/ChangeLog *** > > 2016-08-01 Thomas Preud'homme > > * config/arm/t-aprofile (MULTILIB_EXCEPTIONS): Rewrite into ... > (MULTILIB_REQUIRED): This by specifying multilib needing to be built > rather than those that should not be built. > > > The output of "tree lib/gcc/arm-none-eabi/7.0.0" before and after the patch > shows that the same set of multilib is being built. > > Is this ok for trunk? > > Best regards, > > Thomas