YJIT: Avoid splitting mov for small values on arm64

[k0kubun]

When Mov's destination is a register and the source is an immediate which cannot be encoded with a bitmask but is <= 0xffff, it can be a single mov instruction.

Currently, split_bitmask_immediate splits such source operands, which are still necessary for other instructions, so this PR avoids calling it for that case.

While I don't see a significant impact on benchmarks, this should help the performance of stack temp register allocation on arm64 #7659 a little.

Example

before

  # Insn: 0000 putobject (stack_size: 0)
  # reg_temps: 00000000 -> 00000001
  0x1065d0090: mov x11, #5
  0x1065d0094: mov x1, x11

after

  # Insn: 0000 putobject (stack_size: 0)
  # reg_temps: 00000000 -> 00000001
  0x103840090: mov x1, #5

[XrXr]

Nice!

Off topic, sometimes our asm.mov generates orr in the disassembly because I think for small values movz gets the mov mnemonic. Might want to change the selection there just for the looks of the disassembly.

[k0kubun]

Off topic, sometimes our asm.mov generates orr in the disassembly because I think for small values movz gets the mov mnemonic. Might want to change the selection there just for the looks of the disassembly.

I would like a non-orr output too, but is there an instruction that's useful for this? I believe we can't control what libcapstone outputs when multiple instructions have the same encoding, so I'm assuming you're talking about a different instruction, but is that still a mov-like one?

edit: I guess you meant to choose mov over movz for such cases. I'm a bit confused since I'm not sure what conditions lead to the orr output. Is it the Alias Conditions of ORR (immediate)?

[XrXr]

I'm not very sure what exactly is going on either. It might be wishful thinking that Capstone tries to follow the spec when picking mnemonics. I'll start taking notes when I see orr and not spend dedicated time on this hah.