Unless you implement the larger load/stores, the comment is wrong now as this does (7 bytes or less)

It seems like Arm64 should do 16-bytes at a time.
If you grab a FP/Vector register it would be the same as X64

LDR Q0, [addr]
STR Q0, [addr]

@briansull I was deferring doing 16 bytes at a time.

• I was just trying to get this to work. Trying to walk before run.
• ldp/stp with integer register might be slightly faster than ldr/str Q, but I needed to figure out how to allocate a pair of adjacent registers if I wanted to use ldp/stp (if I remember the instruction encoding form correctly).
• I needed to look at the armv8 spec for alignment requirements.
• I was concerned about using FP registers and its impact on Linux kernel context switch. This is probably not a real issue.

So I just looked at the armv8 spec. Per B2.4.2 Alignment of data accesses -- ldr V0 would require an 16 byte aligned address. VLD1 V0.16B would have no alignment requirements.

Is there any cpBlk alignment guarantee? I assume it is guaranteed to be 8 byte aligned.

First the LDP/STP instructions do not require adjacent register number, any two registers can be used. So you can use two integer registers if you want to avoid using FP.

I don't think that there is an alignment requirement except that the actual SP register must be aligned. (if n == 31 thenCheckSPAlignment();)

My manual for B2.4.2 reads:

The alignment requirements for accesses to Normal memory are as follows:
For all instructions that load or store a single or multiple registers, other than
Load-Exclusive/Store-Exclusive and Load-Acquire/Store-Release, if the address that is accessed is not aligned to the size of the data element being accessed, then one of the following occurs:
— An Alignment fault is generated.
— An unaligned access is performed.
SCTLR_ELx.A at the current Exception level can be configured to enable an alignment check, and thereby determine which of these two options is used.

• For all Load-Exclusive/Store-Exclusive and Load-Acquire/Store-Release memory accesses that access a single element or a pair of elements, an Alignment fault is generated if the address being accessed is not aligned to the size of the data structure being accessed

Key phrase is "one of the following occurs: — An Alignment fault is generated." If SCTLR.A is set an alignment fault will fire. It would be safer to generate code which does not assume SCTLR.A == 0.

Thanks for the LDP tip. I hadn't gotten a chance to recheck that yet.

Floating point offers code size advantages. For instance, VLD1 V0, V1, V2, V3, [Xn] could load the whole block in a single instruction, but the adjacency requirements makes me avoid trying this. I assume lrsa does not already support requesting adjacent registers.

Yeah, I don't think that lsra has any support (yet) for adjacent register requirements.

You would also have to teach lower to reserve both a fp/vector register and an integer register.
But x64 also must have that logic already.

If we switch to Q reg we should be able to just use one the FP register.

Well if you are copying an odd number of bytes you use the FP register to do the multiple of 16 amount and the integer register to do the rest.

Yes, but you can do the rest with the same FP register on arm64. You just use the single lane forms of the ST1 Vt.B[0], [ Xn ]

Yeah, I hadn't consider using those instructions. The ARM64 encoder does support them. I remember implementing them.

This is inconsistent with the design. Should use emitIns_S_R() for the store

Yeah, That part isn't implemented yet.
The problem is that there isn't encoding space available to encode both registers in the instruction, because one register in the encoding is reserved for something else (larger SP offsets)