[LLVMdev] How to resolve decoding conflict?

[Hal Finkel]

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 ;) )

 -Hal

----- Original Message -----
> From: "David Wiberg" <dwiberg at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Wednesday, July 9, 2014 2:49:55 PM
> Subject: [LLVMdev] 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory