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

[Ricky Taylor via llvm-dev]

On Mon, 30 Aug 2021 at 07:28, Min-Yih Hsu <minyihh at uci.edu> wrote:
>
> Hi Ricky,
> ...
>
> I haven't looked into this problem TBH.
Cool, in that case, let's worry about CCR allocation after at least
thinking through the
instruction encoding.

> Regarding the permutation problem...I also feel the pain in terms of maintenance...
I'm still wondering if we can just represent EA operands as a single
operand type
(or rather, one per operand size). We only really need one parameter
per operand instance,
which is which modes are legal. The EA bits are encoded in very few
ways, so I suspect we
could legitimately use some TSFlags bits for that.

That way, we would only really be supporting a few broad cases of operand types:
- EA operands
- Immediate operands
- Register masks (and other special purpose operand types)

I don't think having a few permutations per instruction is bad, it's
just with the EA operand
types, we could end up with like 26^2 instruction instances if an
instruction had two
EA operands. I'm not sure that's feasible to solve even with multiclasses.

I've poked around the tablegen emitter code and it looks feasible to do a phased
migration with a small tweak to tablegen. We would then just need to check if we
have code beads defined for an instruction, if we don't we can follow a new
tablegen-based code path.

I think I'm going to do some further investigation into this as a
possible solution.
Give me a shout if there's something I've missed.

Thanks,
Ricky