[CodeEmitter] Support instruction widths > 64 bits
commit41e3905aa8e0b87b05b8567510256383a3434fd4
authorJames Molloy <jmolloy@google.com>
Sun, 15 Sep 2019 08:35:08 +0000 (15 08:35 +0000)
committerJames Molloy <jmolloy@google.com>
Sun, 15 Sep 2019 08:35:08 +0000 (15 08:35 +0000)
treeffc9cc8833a679bd621e6edd658262ff72e5ded1
parent88ae6d603d6068faa4edf18c01531c4fcef6d85e
[CodeEmitter] Support instruction widths > 64 bits

Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).

This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).

When Inst.BitWidth > 64 the prototype changes to:

  void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
                                                  SmallVectorImpl<MCFixup> &Fixups,
                                                  APInt &Inst,
                                                  APInt &Scratch,
                                                  const MCSubtargetInfo &STI);

The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.

Similarly the operand encoding prototype changes to:

  getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);

That is, the operand is passed by reference as APInt rather than returned as uint64_t.

To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371928 91177308-0d34-0410-b5e6-96231b3b80d8
test/TableGen/BigEncoder.td [new file with mode: 0644]
test/TableGen/RegisterEncoder.td
utils/TableGen/CodeEmitterGen.cpp