[LLVMdev] How to resolve decoding conflict?

[David Wiberg]

2014-07-09 22:07 GMT+02:00 Hal Finkel <hfinkel at anl.gov>:
> 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
>

Hi Hal,

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

- David

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