[llvm] [M68k] Do not allow addressing modes k and q as MOVE targets (llvm#200826) (PR #201653)

[Michael Karcher via llvm-commits]

================
@@ -33,14 +33,6 @@ foreach size = [8, 16, 32] in {
   def : Pat<(!cast<SDPatternOperator>("atomic_store_"#size) !cast<MxRegOp>("MxDRD"#size):$val, MxCP_ARID:$ptr),
             (!cast<MxInst>("MOV"#size#"pd") !cast<MxMemOp>("MxARID"#size):$ptr,
                                             !cast<MxRegOp>("MxDRD"#size):$val)>;
-
-  def : Pat<(!cast<SDPatternOperator>("atomic_store_"#size) !cast<MxRegOp>("MxDRD"#size):$val, MxCP_PCD:$ptr),
----------------
karcherm wrote:

I wonder whether explicit tests for these changes are necessary. This removal was required because these `atomic_store` patterns defined a lowering to some invalid MOV patterns that were removed in this PR. There no longer is `MOV8qd`, `MOV32kd` and the like, so if a regression would happen that assumes these MOV patterns exist, llvm would fail to buidl. This might well be good enough.

On the other hand, it might make sense to test whether llvm is still able to handle atomic stores to targets with PC-relative addresses, so a test might make some sense indeed. I totally do not care what approach is used instead of the invalid PC-relative MOV target. Most likely a combination of LEA and MOV is emitted, loading the PC-relative target address into an address register, but any other way to perfom the MOV (e.g. somthing like `BSR .+4; POP %A4; ADDA.L $14,%A4; MOV D0,%A4@`, I surely got the M68k assembly syntax wrong, but you likely get what I mean) would be fine with me as well. I'm hesitant to add a test case that requires generating some specific way to deal with "you can't use a PC-relative address as destination in MOV" if all what this PR should do is to encourage llvm to pick *any* way to deal with it. That's also why my test case for MOV only has a ´CHECK-NOT` for the invalid pattern, but no `CHECK` line.

https://github.com/llvm/llvm-project/pull/201653