[PATCH] aarch64: Support for FEAT_LSUI

[Richard Earnshaw (lists)]

On 07/05/2025 13:49, Ezra.Sitorus@arm.com wrote:
> diff --git a/gas/testsuite/gas/aarch64/lsui.s b/gas/testsuite/gas/aarch64/lsui.s
> new file mode 100644
> index 00000000000..2d30ac2159e
> --- /dev/null
> +++ b/gas/testsuite/gas/aarch64/lsui.s
> @@ -0,0 +1,634 @@
> +ldtxr:
> +	ldtxr	w0, [x0]
> +	ldtxr	w0, [sp]
> +	ldtxr	w30, [x0]
> +	ldtxr	x0, [x0]
> +	ldtxr	x0, [sp]
> +	ldtxr	x30, [x0]

I haven't done a full review of this patch, but just a note on the register values we use for testing, and the reason for picking them.

The point of testing the specific register values is to ensure that the register number is encoded in the correct field and that the full range of the field is correctly written (ie that we don't accidentally mask of too many bits).  For most registers the bits in the opcode are consecutive, so tests can be kept quite simple, given that we don't have to check that the bits are assigned to the right sub-field.  Using x30, though fails to check that bit 0 of the register field is writeable, so for simple tests, if Xzr (or Wzr if appropriate) are not valid for an instruction, I think it's better to use x29 (0x1d) as this sets both the top and bottom bits in the register field; x23 (0x17) would be equally good since both of these values just leave one internal bit unset.

In these particular instructions, though, I think it's better to use [WX]zr, since that also checks that the parser is using the correct register check.  Note it doesn't matter that an instruction using Xzr in a particular field might be pretty pointless, we're not testing that, just that the assembler is handling the encodings correctly and setting the right bits in the instruction.

For instructions where the register field is discontiguous, we need more checks to ensure that the register value is correctly partitioned across the encoding, but that's not the case here, I suspect.

R.