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...@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...@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...@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...@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
