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

[David Spickett via Phabricator via llvm-commits]

DavidSpickett added a comment.

As I understand it, clang is correct to reject `movs  pc, r1, lsl r2` as this is unpredictable.

(mostly the same references Peter used, but this confusing enough I'll restate them)

  F5.1.113 MOV, MOVS (register-shifted register)
  
  Decode for all variants of this encoding
   d = UInt(Rd); m = UInt(Rm); s = UInt(Rs);
   setflags = (S == '1'); shift_t = DecodeRegShift(stype);
   if d == 15 || m == 15 || s == 15 then UNPREDICTABLE

The other one is merely "deprecated" and I don't know about GAS but we certainly don't have any way to signal that, so accepting it is fine. You can justify that by citing `F5.1.112 MOV, MOVS (register)` in the latest ARMARM.
The actual wording is rather confusing (and potentially has some typos, I'll flag this up) but the main point is that the only conditions listed there are for "deprecated" not "unpredictable" and that's all the assembler needs to know.

The reasoning, I think Peter's explanation about the exception handling case covers it as best I could. I don't think you need that reasoning to justify clang's choice though.

  If I should send a kernel patch, how should I justify it?
  
  If we should support this form of this instruction with these operands, how should I proceed on this patch?

Send a kernel patch, with the justification that the instruction is unpredictable according to the spec and so GAS should be rejecting it anyway, just like clang.

There are other lines that encode unpredictable instructions but use the encoding directly to subvert GAS's checks so you could do that:

  TEST_UNSUPPORTED(__inst_arm(0xe15c0f1e) " @ cmp r12, r14, asl pc"

No mysterious gap in the tests that way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95586