How to resolve decoding conflict?

Hi all,

Short version
I get decoding conflicts during generation of disassembler tables for
my modified PowerPC backend:
  001100..........................
  ................................
  ADDIC 001100__________________________
  E_LBZ 001100__________________________

Which methods can be used to resolve this kind of error?

Long version:
I'm trying to implement support for the PowerPC Variable Length
Encoding (VLE) instruction set. This is an instruction set which
re-encodes many of the normal PPC instructions for improved code
density. There exists both cores which are only able to run VLE
instructions and cores which can run a mix of VLE and non-VLE code.
There exists instructions in the VLE instruction set which have the
same encoding as non-VLE instructions.

In my implementation I'm trying to reuse as much as possible from the
existing PPC backend. My first goal is to target a VLE only core and
my strategy so far has been to mark my VLE instructions with a
predicate to require VLE support from the sub target.

Example:
def HasVLE : Predicate<"PPCSubTarget->hasVLE()">,
AssemblerPredicate<"FeatureVLE", "VLE Instruction set">;

let Predicates = [HasVLE] in {

If I have understood this correct the predicate will work for CodeGen
and the assembler but not for the disassembler. This has worked for
the instructions added up until now when I added an instruction whose
encoding conflicts with a non-VLE instruction and I receive an error
during generation of disassembler tables.

My question is how to resolve this decoding conflict?
One option I considered would be to remove all non-VLE instructions
but I would like to avoid that. Another option would perhaps be to set
a custom DecoderMethod but if possible I would rather do this in
TableGen.

Any pointers for how to proceed with this is appreciated.

- David

David,

If the VLE instructions overlap with the regular ones, you'll want to put into into a different decoder namespace. You can put:

let DecoderNamespace = "VLE" in {

...

}

around the relevant definitions and that should take care of the decoding conflicts.

Then, in the disassembler, you'll want something like:

  if ((STI.getFeatureBits() & PPC::FeatureVLE) != 0) {
    DecodeStatus result =
      decodeInstruction(DecoderTableVLE32, MI, Inst, Address, this, STI);
    if (result != MCDisassembler::Fail)
      return result;

    MI.clear();
  }

before

  return decodeInstruction(DecoderTable32, MI, Inst, Address, this, STI);

(but I suppose they're not all 32-bits, so I presume it will be more complicated :wink: )

-Hal

David,

If the VLE instructions overlap with the regular ones, you'll want to put into into a different decoder namespace. You can put:

let DecoderNamespace = "VLE" in {

...

}

around the relevant definitions and that should take care of the decoding conflicts.

Then, in the disassembler, you'll want something like:

  if ((STI.getFeatureBits() & PPC::FeatureVLE) != 0) {
    DecodeStatus result =
      decodeInstruction(DecoderTableVLE32, MI, Inst, Address, this, STI);
    if (result != MCDisassembler::Fail)
      return result;

    MI.clear();
  }

before

  return decodeInstruction(DecoderTable32, MI, Inst, Address, this, STI);

(but I suppose they're not all 32-bits, so I presume it will be more complicated :wink: )

-Hal

Hi Hal,

Thank you, this seems like a good idea which I will try.

- David