[PATCH] D109657: [SystemZ] Accept plain register name where an address is expected.

Ulrich Weigand via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 20 03:16:50 PDT 2021


uweigand added a comment.

In D109657#3008172 <https://reviews.llvm.org/D109657#3008172>, @jonpa wrote:

>> I believe %reg should be treated equivalently to 0(%reg) for any type of address, including those with length or vector index, so this should be fine. However, it would be good to validate that behavior against GAS, and also add a few test cases for instructions with those address types.
>
> For addresses with a Length field, it seems GAS does require the full address with the explicit displacement as well:
>
>           xc      0(32,%r2), 0(%r2)
>           xc      0(32,%r2), %r2
>   #       xc      (32,%r2), %r2    # not accepted by GAS
>   #       xc      32,%r2, %r2      # not accepted by GAS

Yes, if you have a length field, you need the full address.  I was wondering whether you can omit the length field completely, e.g. have something like

  xc %r2, %r2

but it looks like this is isn't accepted anyway as the length is mandatory (makes sense to me as well).

>> An interesting twist is that you have to use the full name (%rX); if you were to use just the register number (1-15), it would be considered a displacement instead of a register ...
>
> Hmmm... to my surprise it now seems that GAS is treating a plain register name as an offset:
>
>   lg      %r0, 0(%r1)
>   lg      %r0, %r1
>   lg      %r0, 1
>
> -> as ; objdump ->
>
>   Disassembly of section .text:
>   
>   0000000000000000 <.text>:
>      0:	e3 00 10 00 00 04 	lg	%r0,0(%r1)
>      6:	e3 00 00 01 00 04 	lg	%r0,1
>      c:	e3 00 00 01 00 04 	lg	%r0,1
>
> With this patch though as we agreed:
>
>   llvm-mc --show-encoding
>   	.text
>   	lg	%r0, 0(%r1)                     # encoding: [0xe3,0x00,0x10,0x00,0x00,0x04]
>   	lg	%r0, 0(%r1)                     # encoding: [0xe3,0x00,0x10,0x00,0x00,0x04]
>   	lg	%r0, 1                          # encoding: [0xe3,0x00,0x00,0x01,0x00,0x04]

Huh, this is a problem.  We'll need to verify this with the binutils team -- that behavior seems just broken to me.   (And if the current behavior of GAS is just broken, then I'm wondering whether the correct fix isn't rather to make this an error in GAS too, and not change LLVM at all ...)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109657/new/

https://reviews.llvm.org/D109657



More information about the llvm-commits mailing list