[PATCH] D44815: [AArch64]: Add support for parsing rN registers.

[Manoj Gupta via Phabricator via cfe-commits]

manojgupta added a comment.

Add more context from the email communication with Peter Smith and Robin Murphy.

On 22/03/18 02:34, Manoj Gupta wrote:

> Hi Robin,
> 
> this is Manoj from Google. I was looking into implementing support for
>  parsing "r" registers in clang for AArch64 based on lkml thread
>  https://lkml.org/lkml/2018/3/1/186 ).
> 
> On the llvm bug(https://bugs.llvm.org/show_bug.cgi?id=36862#c2 ), Peter had
>  a comment that I think could be better clarified by you.
> 
> "
>  Can you be a bit more specific about where in GCC "rn" is acceptable? It is
>  certainly not true in the general case, for example:
>  ...
>  "
>  Further, my understanding is that binutils does not support "r" registers
>  in AArch64.
>  So is it correct that  GCC support limited to parsing "r" registers as "x"
>  registers and assembler will never see "r" registers?

There are two distinct things being conflated here: "r0" is not, and
never has been, a valid A64 assembly *operand*, thus indeed should never
be passed to AArch64 binutils since the latter only consumes A64
assembly syntax.

The "register ... asm("r0")" case, however, is an command to the
compiler's register allocator, not an operand to any individual assembly
instruction. GCC documents this syntax as "...the name of the register
that should be used.", and section https://reviews.llvm.org/B1.2.1 of the Armv8 ARM[1] is quite
clear that the fundamental AArch64 registers are named R0-R30, SP, PC,
and V0-V31. It seems perfectly straightforward to me that the register
allocator would work in units of fundamental machine registers, while
access/element sizes only start to matter in the subsequent assembly
generation phase where actual instruction accesses to those registers
are emitted (and indeed where those sizes depend more on each specific
operation than the inherent size of the type being operated on).

I note that Clang *does* already understand references to SIMD&FP "V"
registers in this context as expected[2] without demanding an explicit
access or element size.

Robin.

[1]
https://developer.arm.com/products/architecture/a-profile/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/567872.html


Repository:
  rC Clang

https://reviews.llvm.org/D44815