[PATCH] D95586: [ARM] permit PC as destination of MOVS

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 30 04:47:21 PST 2021


psmith added a comment.

Not much to add over what Renato has said. I've put some context into the special meaning of MOVS with the PC as destination. I'm not entirely sure why the MOVS with immediate is unrestricted, my guess is that it is a historical quirk of the encoding and has likely never been used.

MOVS with the PC as destination has a special meaning in AArch32 for returning from exceptions (see examples in https://developer.arm.com/documentation/dui0056/d/handling-processor-exceptions/entering-and-leaving-an-exception/the-return-address-and-return-instruction). It has the extra property of restoring the CPSR from the banked SPSR. I would expect that the kernel code is doing an exception return as I think its use outside of that is CONSTRAINED UNPREDICTABLE. There aren't that many alternatives, RFE and something like LDMFD sp!,{R0-R12,pc}^ (the ^ indicates an exception return) coming to mind.

It will be worth looking at the Arm ARM for the conditions

F5.1.112 MOV, MOVS (register)
PC as destination:

  The MOVS variant of the instruction performs an exception return without the use of the stack. In this case:
  — The PE branches to the address written to the PC, and restores PSTATE from SPSR_<current_mode>.
  — The PE checks SPSR_<current_mode> for an illegal return event. See Illegal return events from
  AArch32 state on page G1-5524.
  — The instruction is UNDEFINED in Hyp mode.
  — The instruction is CONSTRAINED UNPREDICTABLE in User mode and System mode.

Later in Assembler Symbols (Arm encoding)

  For the MOVS variant, the instruction performs an exception return, that restores PSTATE
  from SPSR_<current_mode>. Arm deprecates use of the instruction if <Rn> is not the LR,
  or if the optional shift or RRX argument is specified.

Which implies that ideally only `MOVS pc, lr` should be used, but deprecation doesn't mean can't be used.

F5.1.113 MOV, MOVS (register-shifted register)
Does not permit use of the PC in the registers `if d == 15 || m == 15 || s == 15 then UNPREDICTABLE;`



================
Comment at: llvm/test/MC/ARM/lsl-zero-errors.s:157
+
+        movs  pc, r1, lsl r2
+
----------------
I think this is unpredictable as it is the encoding MOV, MOVS (register-shifted register) which does not permit PC as the destination, only MOV, MOVS (register) permits PC as the destination (the encoding allows a rotation, but not shift).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95586



More information about the llvm-commits mailing list