From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10651 invoked by alias); 8 May 2015 08:31:25 -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 10641 invoked by uid 89); 8 May 2015 08:31:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Fri, 08 May 2015 08:31:24 +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 E7CAD29; Fri, 8 May 2015 01:30:48 -0700 (PDT) Received: from collaborate-mta1.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTP id D1C1F3F218; Fri, 8 May 2015 01:31:21 -0700 (PDT) Received: from [10.2.206.27] (e105545-lin.cambridge.arm.com [10.2.206.27]) by collaborate-mta1.arm.com (Postfix) with ESMTPS id 5444B13F6FA; Fri, 8 May 2015 03:31:20 -0500 (CDT) Message-ID: <554C7459.4000806@arm.com> Date: Fri, 08 May 2015 08:31:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sandra Loosemore , Christian Bruel CC: "gcc-patches@gcc.gnu.org" , Richard Earnshaw , "nickc@redhat.com" Subject: Re: [PATCH, ARM] attribute target (thumb,arm) [4/6] respin (4th) References: <554A243B.8010902@st.com> <554A9DB1.1070009@codesourcery.com> In-Reply-To: <554A9DB1.1070009@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00627.txt.bz2 I'm still playing with the code, so this is a partial review. We should prevent inlining of ARM state functions into functions we know will be T16 if !TARGET_SOFT_FLOAT on the grounds that the architecture doesn't have floating point instruction encodings in the T16 ISA (Thumb1). We'll just cause internal compiler errors if we allow this. On 07/05/15 00:03, Sandra Loosemore wrote: > On 05/06/2015 08:24 AM, Christian Bruel wrote: >> diff '--exclude=.svn' -ruN gnu_trunk.p3/gcc/gcc/doc/extend.texi gnu_trunk.p4/gcc/gcc/doc/extend.texi >> --- gnu_trunk.p3/gcc/gcc/doc/extend.texi 2015-05-06 09:00:31.232943164 +0200 >> +++ gnu_trunk.p4/gcc/gcc/doc/extend.texi 2015-05-06 14:50:05.632612233 +0200 >> @@ -3419,6 +3419,25 @@ >> the compiler rejects attempts to specify an alternative. >> @end table >> >> +@item target (@var{options}) >> +@cindex @code{target} function attribute >> +As discussed in @ref{Common Function Attributes}, this attribute >> +allows specification of target-specific compilation options. >> + >> +On ARM, the following options are allowed: >> + >> +@table @samp >> +@item thumb >> +@cindex @code{target("thumb")} function attribute, ARM >> +Force Thumb1 Thumb2 code generation depending on the architecture. > > "Force Thumb or Thumb-2 code generation, depending on the architecture." I'd rather it said something like "Force code generation in the Thumb (T16/ T32) ISA. The exact instructions chosen depends on the architecture levels chosen." >> + >> +@item arm >> +@cindex @code{target("arm")} function attribute, ARM >> +Force ARM code generation. "Force code generation in the ARM (A32) ISA." >> +@end table >> + >> +Functions from different modes can be inlined using the caller mode. Rewrite this based on the review comment about inlining in the Thumb16 state from ARM state. > > "...the caller's mode." > >> + >> @node AVR Function Attributes >> @subsection AVR Function Attributes >> >> @@ -18436,8 +18455,9 @@ >> @xref{Function Attributes}, for more information about the >> @code{target} attribute and the attribute syntax. >> >> -The @code{#pragma GCC target} pragma is presently implemented for >> -x86, PowerPC, and Nios II targets only. >> +The @code{#pragma GCC target} pragma is implemented for >> +ARM, x86, PowerPC, and Nios II targets. >> + I'd rather say this once we have proper support with arch, cpu and fpu options enabled. Until such a time I think this hunk is a bit premature. Ramana