[llvm-dev] [M68k] CCR usage / instruction encoding

[Ricky Taylor via llvm-dev]

Hi,

I've been angling at migrating changes from my proof-of-concept Mega Drive fork
back into mainline LLVM. There are a fair few smaller pieces (a few extra
instruction implementations, some minor bug fixes) but the fork itself made some
large changes in order to get a working demo on the hardware proper.

Additionally, as it was part of a proof-of-concept (and I lack experience
working on the LLVM backend), a lot of the original implementation is not going
to have been implemented in the best way.

I'm hesitant to try and migrate any of the smaller changes before some of the
larger questions are answered because it might result in redundant work.

The two biggest areas of concern I have are:

- CCR usage
  - At the moment, the M68k target doesn't actually support the 68000, because
    it relies on saving the CCR which wasn't introduced until the 68010.
    (You can save the SR, which includes the CCR, but that is a privileged
    instruction.)
  - In my PoC for the Mega Drive, I disabled allocation of the CCR and had the
    code generate CCR in the immediately preceding instruction - this was
    flaky because sometimes the instructions got split

- Instruction encoding
  - This is the point of discussion of PR48792: Review options between using
    CodeBeads v.s. TSFlags (https://bugs.llvm.org/show_bug.cgi?id=48792)
  - The code-beads implementation is particularly painful for disassembly,
    even the landed disassembler feels messy
  - There is an instruction definition per set of operand permutations in
    the M68k backend, which makes manipulating the instructions in the
    backend outside of codegen quite difficult
  - I wrote up some thoughts in a previous message:
    https://lists.llvm.org/pipermail/llvm-dev/2021-February/148408.html

I'm happy to put some effort into either of these problems, though I could
definitely benefit from some guidance.

I'm not entirely sure what the process is from here. Prepare an RFC
for any major changes and start landing incrementally once they achieve
some kind of consensus?

Thanks,
Ricky Taylor