From patchwork Wed Aug 10 15:51:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Preudhomme X-Patchwork-Id: 657733 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3s8bHc0cS7z9sxR for ; Thu, 11 Aug 2016 01:51:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=vkKP8JCq; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :references:subject:to:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=YhpLp14+zlzg7y0TB MYztUOn6/n1rrPfHnYhaaAELwc/zOTeadak0UTzEyycQ8wqMjmemq7YWxOdiSPMF aWAIr7TIR+zhhE3yrchmA47jDACb5LHkmh+eg1DkORvrHPhjG6eLvOO92FW2pQ8F f9h/86/oqcbRp5CDGKmI7FGJv8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :references:subject:to:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=ISyh5MC/tITzJUwiDEhm1Ev DDmo=; b=vkKP8JCqmOJVrjQ/wGHKuJ/IYY/SFLX4AF/eAslNMhZ/g+Ioq2lZKb7 fLP+KL+ximNvQtGlRqolRwCYR5A2ObVCz3xx6jK3n1os5IXwFnva9rLMiFZ8Nrph uBax3OP8G/Adf5uqJ1rnKAAUFbBC2LJ+BBzzOjqrRjVoZxE+Wye0= Received: (qmail 18301 invoked by alias); 10 Aug 2016 15:51:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 18231 invoked by uid 89); 10 Aug 2016 15:51:36 -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=forces, Matches, sk:multili, fpu 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, 10 Aug 2016 15:51:26 +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 B15E0BF3 for ; Wed, 10 Aug 2016 08:52:52 -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 5D4773F487 for ; Wed, 10 Aug 2016 08:51:24 -0700 (PDT) References: <7a028fc9-af84-5214-5eb3-87d87f29dd49@foss.arm.com> Subject: Fwd: [PATCH, ARM] Use a MULTILIB_REQUIRED approach for aprofile multilib To: gcc-patches@gcc.gnu.org From: Thomas Preudhomme X-Forwarded-Message-Id: <7a028fc9-af84-5214-5eb3-87d87f29dd49@foss.arm.com> Message-ID: Date: Wed, 10 Aug 2016 16:51:23 +0100 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> X-IsSubscribed: yes Forwarding to gcc-patches which I forgot past patch #1 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 diff --git a/gcc/config/arm/t-aprofile b/gcc/config/arm/t-aprofile index 0d91006d4ef51a765e849079fd43679175466a71..90305e1206e3964e08a673e385d3198747bdffa1 100644 --- a/gcc/config/arm/t-aprofile +++ b/gcc/config/arm/t-aprofile @@ -49,33 +49,27 @@ MULTILIB_DIRNAMES += fpv3 simdv1 fpv4 simdvfpv4 simdv8 MULTILIB_OPTIONS += mfloat-abi=softfp/mfloat-abi=hard MULTILIB_DIRNAMES += softfp hard -# We don't build no-float libraries with an FPU. -MULTILIB_EXCEPTIONS += *mfpu=vfpv3-d16 -MULTILIB_EXCEPTIONS += *mfpu=neon -MULTILIB_EXCEPTIONS += *mfpu=vfpv4-d16 -MULTILIB_EXCEPTIONS += *mfpu=neon-vfpv4 -MULTILIB_EXCEPTIONS += *mfpu=neon-fp-armv8 - -# We don't build libraries requiring an FPU at the CPU/Arch/ISA level. -MULTILIB_EXCEPTIONS += mfloat-abi=* -MULTILIB_EXCEPTIONS += mfpu=* -MULTILIB_EXCEPTIONS += mthumb/mfloat-abi=* -MULTILIB_EXCEPTIONS += mthumb/mfpu=* -MULTILIB_EXCEPTIONS += *march=armv7-a/mfloat-abi=* -MULTILIB_EXCEPTIONS += *march=armv7ve/mfloat-abi=* -MULTILIB_EXCEPTIONS += *march=armv8-a/mfloat-abi=* - -# Ensure the correct FPU variants apply to the correct base architectures. -MULTILIB_EXCEPTIONS += *march=armv7ve/*mfpu=vfpv3-d16* -MULTILIB_EXCEPTIONS += *march=armv7ve/*mfpu=neon/* -MULTILIB_EXCEPTIONS += *march=armv8-a/*mfpu=vfpv3-d16* -MULTILIB_EXCEPTIONS += *march=armv8-a/*mfpu=neon/* -MULTILIB_EXCEPTIONS += *march=armv7-a/*mfpu=vfpv4-d16* -MULTILIB_EXCEPTIONS += *march=armv7-a/*mfpu=neon-vfpv4* -MULTILIB_EXCEPTIONS += *march=armv8-a/*mfpu=vfpv4-d16* -MULTILIB_EXCEPTIONS += *march=armv8-a/*mfpu=neon-vfpv4* -MULTILIB_EXCEPTIONS += *march=armv7-a/*mfpu=neon-fp-armv8* -MULTILIB_EXCEPTIONS += *march=armv7ve/*mfpu=neon-fp-armv8* + +# Option combinations to build library with + +# Default CPU/Arch (ARM is implicitly included because it uses the default +# multilib) +MULTILIB_REQUIRED += mthumb + +# ARMv7-A +MULTILIB_REQUIRED += *march=armv7-a +MULTILIB_REQUIRED += *march=armv7-a/mfpu=vfpv3-d16/mfloat-abi=* +MULTILIB_REQUIRED += *march=armv7-a/mfpu=neon/mfloat-abi=* + +# ARMv7VE +MULTILIB_REQUIRED += *march=armv7ve +MULTILIB_REQUIRED += *march=armv7ve/mfpu=vfpv4-d16/mfloat-abi=* +MULTILIB_REQUIRED += *march=armv7ve/mfpu=neon-vfpv4/mfloat-abi=* + +# ARMv8-A +MULTILIB_REQUIRED += *march=armv8-a +MULTILIB_REQUIRED += *march=armv8-a/mfpu=neon-fp-armv8/mfloat-abi=* + # CPU Matches MULTILIB_MATCHES += march?armv7-a=mcpu?cortex-a8