From patchwork Mon Feb 17 14:02:10 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrylo Tkachov X-Patchwork-Id: 320993 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 19BA42C00CC for ; Tue, 18 Feb 2014 01:02:24 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=DH/DERz/hkmBK1lzo xyHh8J4Xv1FaBZ+PpUkBC+8QxKqEYtQjgzHi/gxtJSvqA18N3mnsi9s6HnW2AkNf dmjeYRe3UeRIX6E/A49SqcZydb4jMqzuU2IkGPiMonfpAfE83Aac6H+0/MDnUDRj /7K8I6ZzcClDhPAcMn7WUIUNEQ= 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 :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=vu57v7TOTR0xNR/0vIl2J0C b/Ik=; b=N7tOOhMg0aC7Rg/DfSmd24GQaetgwUvQC1UnbalarXXEEYWjC+wsEKj F60u1JJ+nc9QMpsHIO+G011Ry0qkwRjpoLhxWASn8eRFzS7YTkClYDW1Glf9Q8Ka 3Sx7clG6O405zIbTHRo5QrJJm51d6lNH2O5d6/zkIhUzsd+T5nnE= Received: (qmail 24026 invoked by alias); 17 Feb 2014 14:02:17 -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 24017 invoked by uid 89); 17 Feb 2014 14:02:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Feb 2014 14:02:15 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 17 Feb 2014 14:02:12 +0000 Received: from [10.1.208.24] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Feb 2014 14:02:14 +0000 Message-ID: <53021662.4010605@arm.com> Date: Mon, 17 Feb 2014 14:02:10 +0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Richard Henderson CC: GCC Patches Subject: Re: [PATCH][RFC][libatomic] Override -mcpu option for arm linux ifunc targets References: <52EF829A.9010808@arm.com> <52FD0DB6.1090001@redhat.com> In-Reply-To: <52FD0DB6.1090001@redhat.com> X-MC-Unique: 114021714021202601 X-IsSubscribed: yes On 13/02/14 18:23, Richard Henderson wrote: > On 02/03/2014 03:50 AM, Kyrill Tkachov wrote: >> +# For ARM, the -march option by itself conflicts with any -mcpu option that >> +# we might end up passing to the build, causing an error. >> +# Therefore we override the -mcpu option as well. >> +# This shouldn't affect tuning much because the affected code is mostly >> +# in inline assembly anyway. >> @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a -DHAVE_KERNEL64 >> +@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@EXTRA_OVERRIDE = -mcpu=cortex-a9 > Why would you want to split these across two different variables? It's easier > to just add the -march and -mcpu to the same IFUNC_OPTIONS variable. Because IFUNC_OPTIONS is not used as is. It goes through some kind of machinery with the PAT_N, PAT_S, PAT_BASe, PAT_SPLIT above that is used to extract just one of the options from IFUNC_OPTIONS and adding a new entry there ends up messing up the expected order. If there's an easier way to specify the extra option I'll be happy to use it, but I couldn't find a way of doing it without rewriting a whole lot of Makefile magic. > > Why the choice of cortext-a9, as opposed to any of the other v7-a > possibilities? If we're going to force anything, perhaps generic-armv7-a is > more appropriate? Hmmm, you're right. Might as well make it explicit that we want armv7-a. How about this then? Thanks for the review, Kyrill diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in index 46e60c9..b51910a 100644 --- a/libatomic/Makefile.in +++ b/libatomic/Makefile.in @@ -297,7 +297,7 @@ PAT_BASE = $(word 1,$(PAT_SPLIT)) PAT_N = $(word 2,$(PAT_SPLIT)) PAT_S = $(word 3,$(PAT_SPLIT)) IFUNC_DEF = -DIFUNC_ALT=$(PAT_S) -IFUNC_OPT = $(word $(PAT_S),$(IFUNC_OPTIONS)) +IFUNC_OPT = $(word $(PAT_S),$(IFUNC_OPTIONS)) $(word $(PAT_S),$(EXTRA_OVERRIDE)) M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo M_SIZE = -DN=$(PAT_N) M_IFUNC = $(if $(PAT_S),$(IFUNC_DEF) $(IFUNC_OPT)) @@ -313,7 +313,13 @@ M_SRC = $(firstword $(filter %/$(M_FILE), $(all_c_files))) libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix \ _$(s)_.lo,$(SIZEOBJS))) $(am__append_1) $(am__append_2) \ $(am__append_3) +# For ARM, the -march option by itself conflicts with any -mcpu option that +# we might end up passing to the build, causing an error. +# Therefore we override the -mcpu option as well. +# This shouldn't affect tuning much because the affected code is mostly +# in inline assembly anyway. @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a -DHAVE_KERNEL64 +@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@EXTRA_OVERRIDE = -mcpu=generic-armv7-a @ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=i586 @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -mcx16 libatomic_convenience_la_SOURCES = $(libatomic_la_SOURCES)