Also present in go-1.18,19,20.

Weird. It seems to get through the SSA backend ok, but then there is a mis-assembly.
SSA ends with the useless, but correct:

00009 (12) SRL $0, R0, R0

But if I disassemble the binary, there is

  issue64715.go:12      0x78108                 e1a00020                LSR $32, R0, R0                 

Indeed, if I add some unused code to runtime/asm_arm.s like this:

	SRL	$0, R0, R0
	SRL	$1, R0, R0

It disassembles to this:

  asm_arm.s:239         0x757f8                 e1a00020                LSR $32, R0, R0         
  asm_arm.s:240         0x757fc                 e1a000a0                LSR $1, R0, R0          

Good lord, that's horrible: https://stackoverflow.com/questions/66487890/why-different-ranges-of-permitted-shift-values-for-arm-lsl-vs-lsr

Good lord, that's horrible: https://stackoverflow.com/questions/66487890/why-different-ranges-of-permitted-shift-values-for-arm-lsl-vs-lsr

So we probably need to add a rule to rewrite right shift by 0 to left shitt by 0.

@cuonglm That sounds right.
I think we need to handle LSR, ASR that way.
That page also mentions ROR. I'm not sure what we should do with ROR of 0.

Weirdly, our disassembler gets it right. Note the distinction between arg_imm5 and arg_imm5_32.

	case arg_imm5:
		return Imm((x >> 7) & (1<<5 - 1))

	case arg_imm5_32:
		x = (x >> 7) & (1<<5 - 1)
		if x == 0 {
			x = 32
		}
		return Imm(x)

arg_imm5_32 is used for ASR and LSR.

So we probably need to add a rule to rewrite right shift by 0 to left shift by 0.

Shouldn't an ASHR/SRL of 0 just optimize away rather than changing one into another?

But taking a look at the ARM manual, it looks like they've thought ahead about this edge case:

Assemblers can permit the use of some or all of ASR #0, LSL #0, LSR #0, and ROR #0 to specify that no shift is to be performed. This is not standard UAL, and the encoding selected for Thumb instructions might vary between UAL assemblers if it is used. To ensure disassembled code assembles to the original instructions, disassemblers must omit the shift specifier when the instruction specifies no shift.

It looks like this might be something that should get handled at the assembler level to keep things consistent. This case also only applies to constant shifts, see the register version of the instruction vs the immediate version, so no extra work needs to be done on a register based shift of zero

Shouldn't an ASHR/SRL of 0 just optimize away rather than changing one into another?

Certainly fixing the compiler to not issue 0 shifts is worth doing. But since we need to fix the assembler for this issue anyway, that compiler change is not needed to fix this bug. It would just be a performance improvement that could be done independently. (And this bug fix would be nice to get in for 1.22. Performance improvements would wait for 1.23.)

Change https://go.dev/cl/549955 mentions this issue: cmd/asm: fix encoding for arm right shift by constant 0

This just got more complicated because there are not only shift instructions, but shifted register arguments (in fact, the former is implemented using MOV + the latter). We already give errors in some cases for register arguments shifted by bad amounts, like R0>>0.
Maybe we should just error with the 0 right shifts, and fix the compiler to never emit them.

Change https://go.dev/cl/550335 mentions this issue: cmd/asm: for arm, rewrite argument shifted right by 0 to left by 0.