| Message ID | 59368A74.2060908@foss.arm.com |
|---|---|
| State | New |
| Headers | show |
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.. I like the documentation though. 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.
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. > I like the documentation though. 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.
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. > >> I like the documentation though. As an aside %H is not documented here. Noticed it because I am using %H with TImode. 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.
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.
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.
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
On Thu, Aug 31, 2017 at 9:59 AM, Renlin Li <renlin.li@foss.arm.com> wrote: > 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? From my point of view this looks good. Thanks, Andrew > > 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.
commit f8725ffd1375a8347cc8f4f183262c08ce2f73c6
Author: Renlin Li <renlin.li@arm.com>
Date: Tue May 23 16:46:31 2017 +0100
[AARCH64]Add 'r' integer operand modifier. Document the be extend asm modifier
for aarch64 target.
gcc/ChangeLog:
PR target/63359
* config/aarch64/aarch64.c (aarch64_print_operand): Add 'r' modifier.
* doc/extend.texi (AArch64Operandmodifiers): New section.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5707e53..d1c400f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5132,6 +5132,26 @@ aarch64_print_operand (FILE *f, rtx x, int code)
asm_fprintf (f, "0x%wx", UINTVAL (x) & 0xffff);
break;
+ case 'r':
+ {
+ machine_mode mode = GET_MODE (x);
+ switch (mode)
+ {
+ case QImode:
+ case HImode:
+ case SImode:
+ code = 'w';
+ break;
+ case DImode:
+ code = 'x';
+ break;
+ default:
+ output_operand_lossage
+ ("invalid operand mode for register modifier 'r'");
+ }
+ }
+ /* Fall through. */
+
case 'w':
case 'x':
/* Print a general register name or the zero register (32-bit or
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 60a1a3f..d1c830d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8264,7 +8264,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
@@ -8491,7 +8493,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
@@ -8659,6 +8663,70 @@ 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 blow descirbes the list of useful register operand modifiers which
+might be used in extended @code{asm}. It is not necessary a complete list
+of modifiers supported by the AArch64 backend.
+
+@multitable {Modifier} {Print the opcode suffix for the size of th} {Operand}
+@headitem Modifier @tab Description @tab Operand
+@item @code{r}
+@tab Print the opcode suffix for the size of the current integer operand (one of @code{w}/@code{x}).
+@tab @code{%r0}
+@item @code{w}
+@tab Print the SImode name of the register.
+@tab @code{%w0}
+@item @code{x}
+@tab Print the DImode name of the register.
+@tab @code{%x0}
+@item @code{h}
+@tab Print the HFmode name of the register.
+@tab @code{%h0}
+@item @code{s}
+@tab Print the SFmode name of the register.
+@tab @code{%s0}
+@item @code{d}
+@tab Print the DFmode name of the register.
+@tab @code{%d0}
+@item @code{q}
+@tab Print the TFmode name of the register.
+@tab @code{%q0}
+@end multitable
+
+Without specifying any modifiers to a register operand, the default @code{x}
+register name is used for integer operand, @code{v} register name is used for
+floating pointer operand. 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} or
+@code{r}, it will generate the following code as one would expected:
+
+@smallexample
+ldr w0, [x0, x1]
+@end smallexample
+
@anchor{x86Operandmodifiers}
@subsubsection x86 Operand Modifiers