[LLVMdev] [RFC] Hexagon insn table refactoring

[Evandro Menezes]

We are working on enabling the MC code-emitter for Hexagon and it's 
necessary to add the missing opcode bits to the insn tables.

I'm considering scooping the opcode bits from the processor source files 
for correctness' and expediency's sake and I'm afraid that a significant 
refactoring of the current insn tables will be necessary.

I intend to create classes for each insn with the opcode and have the 
current insn definitions use the current names but based on a insn class.

For example, a conditional indirect branch insn is currently defined as:

def JMPR_cdnNotPt_V3: JRInst<(outs),
                              (ins PredRegs:$src1, IntRegs:$src2),
                              "if (!$src1.new) jumpr:t $src2",
                              []>,
                       Requires<[HasV3T]>;

Its new definition would be like this:

let Defs = [PC], isPredicated = 1 in
class V3_J2_jumprfnewpt<list<dag> P = [], string C = ""> : JRInst
   <(outs),
    (ins PredRegs:$Pu, IntRegs:$Rs),
    "if (!$Pu.new) jumpr:t $Rs",
    P, C> {
      bits<2> Pu;
      bits<5> Rs;

      IClass = 0b0101;

      Inst{27-21} = 0b0011011;
      Inst{12-11} = 0b11;
      Inst{9-8} = Pu;
      Inst{20-16} = Rs;
    };

let isReturn = 1, isBarrier = 1, isTerminator = 1 in
def JMPR_cdnNotPt_V3 : V3_J2_jumprfnewpt<>,
                        Requires<[HasV3T]>;

The insn class would be in a separate file included in the file where 
the insns are defined.  So its refactoring will mean that the way in 
which insns are defined will be changed and a new file, added.

Would this be a sensible way to mix a machine-generated file that 
wouldn't be modified often and one that is meant to be hand modified at 
will?

TIA

-- 
Evandro Menezes          Austin, TX          emenezes at codeaurora.org
Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum