Re: [RFC][AARCH64]Add 'r' integer register operand modifier. Document the common asm modifier for aarch64 target.

[Renlin Li <renlin.li@foss.arm.com>]

[-- Attachment #1: Type: text/plain, Size: 3809 bytes --]

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  <renlin.li@arm.com>

         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 <renlin.li@foss.arm.com> wrote:
>>> Hi Andrew,
>>>
>>> On 25/06/17 22:38, Andrew Pinski wrote:
>>>>
>>>> On Tue, Jun 6, 2017 at 3:56 AM, Renlin Li <renlin.li@foss.arm.com> 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  <renlin.li@arm.com>
>>>>>
>>>>>           PR target/63359
>>>>>           * config/aarch64/aarch64.c (aarch64_print_operand): Add 'r'
>>>>> modifier.
>>>>>           * doc/extend.texi (AArch64Operandmodifiers): New section.

[-- Attachment #2: tmp.diff --]
[-- Type: text/x-patch, Size: 3601 bytes --]

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