From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71477 invoked by alias); 31 Aug 2017 16:59:42 -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 71428 invoked by uid 89); 31 Aug 2017 16:59:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=encouraged, flexibility X-HELO: foss.arm.com Received: from usa-sjc-mx-foss1.foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 Aug 2017 16:59:32 +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 15D542B; Thu, 31 Aug 2017 09:59:30 -0700 (PDT) Received: from [10.2.207.43] (e104453-lin.cambridge.arm.com [10.2.207.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 22D463F58F; Thu, 31 Aug 2017 09:59:28 -0700 (PDT) Subject: Re: [RFC][AARCH64]Add 'r' integer register operand modifier. Document the common asm modifier for aarch64 target. To: Andrew Pinski References: <59368A74.2060908@foss.arm.com> <59527975.1060304@foss.arm.com> <5952939E.9010604@foss.arm.com> Cc: "gcc-patches@gcc.gnu.org" , James Greenhalgh , Ramana Radhakrishnan , Richard Earnshaw From: Renlin Li Message-ID: <59A8406F.9040800@foss.arm.com> Date: Thu, 31 Aug 2017 17:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5952939E.9010604@foss.arm.com> Content-Type: multipart/mixed; boundary="------------050509030909090409090302" X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01781.txt.bz2 This is a multi-part message in MIME format. --------------050509030909090409090302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 3809 Hi all, This is a split patch from a discussion here: https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00289.html It contains the document part only. It clarify the behavior when no modifier is used for register operand. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 'H' modifier is added for TImode register pair case. It only documents the most common cases I can think of. Any other suggestions are welcome. Is Okay to trunk? Regards, Renlin gcc/ChangeLog: 2017-08-31 Renlin Li PR target/63359 * doc/extend.texi (AArch64Operandmodifers): New section. On 27/06/17 18:19, Renlin Li wrote: > Hi Andrew, > > On 27/06/17 17:11, Andrew Pinski wrote: >> On Tue, Jun 27, 2017 at 8:27 AM, Renlin Li wrote: >>> Hi Andrew, >>> >>> On 25/06/17 22:38, Andrew Pinski wrote: >>>> >>>> On Tue, Jun 6, 2017 at 3:56 AM, Renlin Li wrote: >>>>> >>>>> Hi all, >>>>> >>>>> In this patch, a new integer register operand modifier 'r' is added. This >>>>> will use the >>>>> proper register name according to the mode of corresponding operand. >>>>> >>>>> 'w' register for scalar integer mode smaller than DImode >>>>> 'x' register for DImode >>>>> >>>>> This allows more flexibility and would meet people's expectations. >>>>> It will help for ILP32 and LP64, and big-endian case. >>>>> >>>>> A new section is added to document the AArch64 operand modifiers which >>>>> might >>>>> be used in inline assembly. It's not an exhaustive list covers every >>>>> modifier. >>>>> Only the most common and useful ones are documented. >>>>> >>>>> The default behavior of integer operand without modifier is clearly >>>>> documented >>>>> as well. It's not changed so that the patch shouldn't break anything. >>>>> >>>>> So with this patch, it should resolve the issues in PR63359. >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 >>>>> >>>>> >>>>> aarch64-none-elf regression test Okay. Okay to check in? >>>> >>>> >>>> I think 'r' modifier is very fragile and can be used incorrectly and >>>> wrong in some cases really.. >>> >>> >>> The user could always (or be encouraged to) opt to a strict register >>> modifier to enforce consistent behavior in all cases. >>> >>> I agree the flexibility might bring unexpected behavior in corner cases. >>> Do you have any examples to share off the top of your head? So that we can >>> discuss the benefit and pitfalls, and decide to improve the patch or >>> withdraw it. >> >> One thing is TImode is missing. I have an use case of __int128_t >> inside inline-asm. >> For me %r and TImode would produce "x0, x1". This is one of the >> reasons why I said it is fragile. >> > > This is true. Actually, I intended to make 'r' only handle the simplest single > integer register case. > So that people won't believe it's a magic thing which could handle everything. > I could improve the description about 'r' to clearly explain it's limitation. > > For TImode integer data, if 'r' is used, it will error > "invalid 'asm': invalid operand mode for register modifier 'r'" > >>> >>>> I like the documentation though. >> >> As an aside %H is not documented here. Noticed it because I am using >> %H with TImode. > > For the document as well, I only document those most common ones which might be used in > inline assembly. It's good to know more use cases. > I could add 'H' into the document. > > Regards, > Renlin > >> >> Thanks, >> Andrew >> >>> >>> Thanks, >>> Renlin >>> >>> >>>> >>>> Thanks, >>>> Andrew >>>> >>>>> >>>>> gcc/ChangeLog: >>>>> >>>>> 2017-06-06 Renlin Li >>>>> >>>>> PR target/63359 >>>>> * config/aarch64/aarch64.c (aarch64_print_operand): Add 'r' >>>>> modifier. >>>>> * doc/extend.texi (AArch64Operandmodifiers): New section. --------------050509030909090409090302 Content-Type: text/x-patch; name="tmp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.diff" Content-length: 3601 diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 03ba8fc..589a6cb 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -8286,7 +8286,9 @@ is undefined if @var{a} is modified before using @var{b}. @code{asm} supports operand modifiers on operands (for example @samp{%k2} instead of simply @samp{%2}). Typically these qualifiers are hardware dependent. The list of supported modifiers for x86 is found at -@ref{x86Operandmodifiers,x86 Operand modifiers}. +@ref{x86Operandmodifiers,x86 Operand modifiers}. The list of supported +modifiers for AArch64 is found at +@ref{AArch64Operandmodifiers,AArch64 Operand modifiers}. If the C code that follows the @code{asm} makes no use of any of the output operands, use @code{volatile} for the @code{asm} statement to prevent the @@ -8513,7 +8515,9 @@ optimizers may discard the @code{asm} statement as unneeded @code{asm} supports operand modifiers on operands (for example @samp{%k2} instead of simply @samp{%2}). Typically these qualifiers are hardware dependent. The list of supported modifiers for x86 is found at -@ref{x86Operandmodifiers,x86 Operand modifiers}. +@ref{x86Operandmodifiers,x86 Operand modifiers}. The list of supported +modifiers for AArch64 is found at +@ref{AArch64Operandmodifiers,AArch64 Operand modifiers}. In this example using the fictitious @code{combine} instruction, the constraint @code{"0"} for input operand 1 says that it must occupy the same @@ -8681,6 +8685,71 @@ error: @} @end example +@anchor{AArch64Operandmodifiers} +@subsubsection AArch64 Operand Modifiers +References to input, output, and goto operands in the assembler template +of extended @code{asm} statements can use +modifiers to affect the way the operands are formatted in +the code output to the assembler. + +The table below descirbes the list of useful register operand modifiers which +might be used in extended @code{asm}. It is not a complete list of modifiers +supported by the AArch64 backend. + +@multitable {Modifier} {Print the opcode suffix for the size of the} {Operand} +@headitem Modifier @tab Description @tab Operand +@item @code{w} +@tab Print 32-bit name of the general purpose register. +@tab @code{%w0} +@item @code{x} +@tab Print 64-bit name of the general purpose register. +@tab @code{%x0} +@item @code{h} +@tab Print 16-bit name of the scalar floating-point register. +@tab @code{%h0} +@item @code{s} +@tab Print 32-bit name of the scalar floating-point register. +@tab @code{%s0} +@item @code{d} +@tab Print 64-bit name of the scalar floating-point register. +@tab @code{%d0} +@item @code{q} +@tab Print 128-bit name of the scalar floating-point register. +@tab @code{%q0} +@item @code{H} +@tab Print the higher numbered 64-bit register name of a pair (TImode) of +general purpose registers. +@tab @code{%H0} +@end multitable + +Without specifying any modifiers to a register operand, the default @code{x} +register name is used for integer operands, @code{v} register name is used for +floating pointer operands. For example: + +@example +int load_int (int *ptr, int offset) +@{ + int result; + asm ("ldr %0, [%1, %2]\n\t" + : "=r" (result) + : "r" (ptr), "r"(offset)); + return result; +@} +@end example + +The following code will be generated: + +@smallexample +ldr x0, [x0, x1] +@end smallexample + +If proper modifier is used for the first operand @code{result}, say @code{w}, +it will generate the following code as one would expect: + +@smallexample +ldr w0, [x0, x1] +@end smallexample + @anchor{x86Operandmodifiers} @subsubsection x86 Operand Modifiers --------------050509030909090409090302--