[PATCH] D52366: [tblgen][disasm] Separate encodings from instructions

Daniel Sanders via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 19 15:28:30 PDT 2018


dsanders added a comment.

In https://reviews.llvm.org/D52366#1269627, @kparzysz wrote:

> The encoding of an instruction includes encodings of its operands.  How are you planning to implement separate encoder/decoder methods?  Right now their names are all embedded into operand definitions.


The follow-on patch, https://reviews.llvm.org/D52369, adds the `AdditionalEncoding` class which defines the encoding in the same way that an Instruction does:

  def : AdditionalEncoding<ADD1> {
    bits<8> Reg;
    bits<16> Inst; // You can also have bits<32> and it will still be a 16-bit encoding
    let Size = 2;
    let Inst{0-3} = 0;
    let Inst{4-7} = Reg;
    let Inst{8-15} = 0;
    ...
  }

the decoders for variable fields like Reg from the above example are going to be inherited from the Instruction that the encoding maps to. This is sufficient for the majority of cases since many compressed ISA's use the same field encoding and only apply tighter range limits for the shorter encodings. There are a few that change the field encoding in a bigger way than merely truncating the bits and that case is currently only supported via AdditionalEncoding.DecoderMethod which would have to extract and decode every operand. I'm thinking that the per-operand DecoderMethods could be done with a field along the lines of:

  list<NameToOperand> OperandOverrides = [NameToOperand<"Reg", SomeOperand>];

where NameToOperand is a class along the lines of:

  class NameToOperand<string name, Operand operand> {
    string Name = name;
    Operand Op = operand;
  }

that would then need to be plumbed into the code responsible for generating the code to extract and decode the variable fields.

The encoding side of things isn't something I've considered much so far since there's non-trivial decisions to be made to pick between the choices of valid encodings and these impact optimization as well as the validity of the generated code (e.g. jump tables sometimes need a known size to calculate the target of the jump). I've generally tried to make sure the AdditionalEncoding class makes sense from an encoder perspective but I haven't given much thought to actually generating an encoder from it yet


Repository:
  rL LLVM

https://reviews.llvm.org/D52366





More information about the llvm-commits mailing list