search for: baseopcode

...pt, Addrr_pf, .. , ..} Addri : { Addrr, Addri, Addri_pt, Addri_pf,.. > Do something like this: > > def getPredicatedOpcode : InstrMapping { > // Only include instructions form the PredRel class. > let FilterClass = "PredRel"; > > // Instructions with the same BaseOpcode field form a row. > let RowFields = ["BaseOpcode"]; > > // Instructions with the same predicate sense form a column. > let ColFields = ["PredSense"]; > > // The key column is the unpredicated instructions. > let KeyCol = ["nopred"]; &gt...

...want. > > Are you saying that the mechanism is already present which allows us to > relate instructions with each other? What do you mean by a proper query > language? Yes, in the very simple sense that you can relate instructions that have the same value in a field: def ADD { let BaseOpcode = "ADD"; let PredSense = "nopred"; } def ADDtrue { let BaseOpcode = "ADD"; let PredSense = "true"; } Inside a multiclass, the NAME variable is set to the base name of the defm. You can use that to relate your instructions. >> You don't want...

...ADD--- ---> ADDtrue -----> ADDtru_new (predicate new form of true) \-----> ADDfalse -----> ADDfalse_new (predicate new form of false) // Define Predicate New relation def getPredNewOpcode : InstrMapping { let FilterClass = "PredNewRel"; let RowFields = ["BaseOpcode"]; // ColFields is a list of flags/attributes of the instructions. let ColFields = ["DotNewType", "PredSense"]; // Here 'DotNewType' of the KeyCol is "" and Predsense can be either 'true' or 'false' let KeyCol = ["", "...

...n the non-predicated instructions and their predicate formats as follows: def getPredOpcode : InstrMapping { // InstrMapping is a new class defined in Target.td // Used to filter instructions that have this kind of relationship let FilterClass = "PredRel"; // Instructions with the same BaseOpcode value form a row. let RowFields = ["BaseOpcode"]; // Instructions with the same predicate sense form a column. let ColFields = ["PredSense"]; // The key column is the unpredicated instructions. let KeyCol = ["nopred"]; // Value columns are PredSense=true and PredSen...

...#39; as a column identifier, there can be many different types of relationships between instructions. Do something like this: def getPredicatedOpcode : InstrMapping { // Only include instructions form the PredRel class. let FilterClass = "PredRel"; // Instructions with the same BaseOpcode field form a row. let RowFields = ["BaseOpcode"]; // Instructions with the same predicate sense form a column. let ColFields = ["PredSense"]; // The key column is the unpredicated instructions. let KeyCol = ["nopred"]; // Value columns are predicate=true...

Hi Everyone, After some more thoughts to the Jacob's suggestion of using multiclasses for Opcode mapping, this is what I have come up with. Please take a look at the design below and let me know if you have any suggestions/questions. I have tried to keep the design target independent so that other targets could benefit from it. 1) The idea is to add 3 new classes into

Jyotsna, I hadn't been following this, so I apologize if this has already been provided, but can you give a quick example of how this functionality is used? Thanks in advance, Hal On Tue, 28 Aug 2012 13:01:17 -0500 "Jyotsna Verma" <jverma at codeaurora.org> wrote: > Hi Jakob, > > Here is the first draft of the patch to add TableGen backend support > for the

...t; ADDtru_new (predicate new form of true) > \-----> ADDfalse -----> ADDfalse_new (predicate new form of false) > > // Define Predicate New relation > def getPredNewOpcode : InstrMapping { > let FilterClass = "PredNewRel"; > > let RowFields = ["BaseOpcode"]; > > // ColFields is a list of flags/attributes of the instructions. > let ColFields = ["DotNewType", "PredSense"]; > > // Here 'DotNewType' of the KeyCol is "" and Predsense can be either 'true' > or 'false' > le...

...tru_new (predicate new form of true) > \-----> ADDfalse -----> ADDfalse_new (predicate new form of > false) > > // Define Predicate New relation > def getPredNewOpcode : InstrMapping { > let FilterClass = "PredNewRel"; > > let RowFields = ["BaseOpcode"]; > > // ColFields is a list of flags/attributes of the instructions. > let ColFields = ["DotNewType", "PredSense"]; > > // Here 'DotNewType' of the KeyCol is "" and Predsense can be either 'true' > or 'false' > le...

Hi Jakob, Here is the first draft of the patch to add TableGen backend support for the instruction mapping tables. Please take a look and let me know your suggestions. As of now, I create one mapping table per relation which results into a long .inc file. So, I'm planning to combine everything into a single table and will include APIs (one per relation) to query from this table. Thanks,

...lib/Target/X86/MCTargetDesc/X86BaseInfo.h:574! i made extensive use of gdb and after debugging i found the line with issue in X86MCCodeEmitter.cpp. Here NumOps=3 (all registers). and CurOp is 1st initialized to 0. then, the following code gets executed; case X86II::MRMDestReg: { EmitByte(BaseOpcode, CurByte, OS); unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 EmitRegModRMByte(MI.getOperand(CurOp), GetX86RegNum(MI.getOperand(SrcRegNum)), CurByte, OS); CurOp = SrcRegNum + 1; break; } so here CurOp becomes 2. After this; it comes to; else { // If there is...

...tru_new (predicate new form of true) > \-----> ADDfalse -----> ADDfalse_new (predicate new form of > false) > > // Define Predicate New relation > def getPredNewOpcode : InstrMapping { > let FilterClass = "PredNewRel"; > > let RowFields = ["BaseOpcode"]; > > // ColFields is a list of flags/attributes of the instructions. > let ColFields = ["DotNewType", "PredSense"]; > > // Here 'DotNewType' of the KeyCol is "" and Predsense can be either 'true' > or 'false' > le...

...se of gdb and after debugging i found the line with >> issue in X86MCCodeEmitter.cpp. >> >> Here NumOps=3 (all registers). and CurOp is 1st initialized to 0. >> >> then, the following code gets executed; >> >> case X86II::MRMDestReg: { >> EmitByte(BaseOpcode, CurByte, OS); >> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 >> EmitRegModRMByte(MI.getOperand(CurOp), >> GetX86RegNum(MI.getOperand(SrcRegNum)), CurByte, >> OS); >> CurOp = SrcRegNum + 1; >> break; >> } >> so her...

...> issue in X86MCCodeEmitter.cpp. >>>> >>>> Here NumOps=3 (all registers). and CurOp is 1st initialized to 0. >>>> >>>> then, the following code gets executed; >>>> >>>> case X86II::MRMDestReg: { >>>> EmitByte(BaseOpcode, CurByte, OS); >>>> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 >>>> EmitRegModRMByte(MI.getOperand(CurOp), >>>> GetX86RegNum(MI.getOperand(SrcRegNum)), CurByte, >>>> OS); >>>> CurOp = SrcRegNum + 1; >>...

...> >>>>>> Here NumOps=3 (all registers). and CurOp is 1st initialized to 0. >>>>>> >>>>>> then, the following code gets executed; >>>>>> >>>>>> case X86II::MRMDestReg: { >>>>>> EmitByte(BaseOpcode, CurByte, OS); >>>>>> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 >>>>>> EmitRegModRMByte(MI.getOperand(CurOp), >>>>>> GetX86RegNum(MI.getOperand(SrcRegNum)), >>>>>> CurByte, OS); >>>>>...

...s=3 (all registers). and CurOp is 1st initialized to 0. >>>>>>>> >>>>>>>> then, the following code gets executed; >>>>>>>> >>>>>>>> case X86II::MRMDestReg: { >>>>>>>> EmitByte(BaseOpcode, CurByte, OS); >>>>>>>> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 >>>>>>>> EmitRegModRMByte(MI.getOperand(CurOp), >>>>>>>> GetX86RegNum(MI.getOperand(SrcRegNum)), >>>>>>>> Cu...

...itialized to 0. >>>>>>>>>> >>>>>>>>>> then, the following code gets executed; >>>>>>>>>> >>>>>>>>>> case X86II::MRMDestReg: { >>>>>>>>>> EmitByte(BaseOpcode, CurByte, OS); >>>>>>>>>> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 >>>>>>>>>> EmitRegModRMByte(MI.getOperand(CurOp), >>>>>>>>>> GetX86RegNum(MI.getOperand(SrcRegNum)), >>&gt...

...>>>>>> >>>>>>>>>>>> then, the following code gets executed; >>>>>>>>>>>> >>>>>>>>>>>> case X86II::MRMDestReg: { >>>>>>>>>>>> EmitByte(BaseOpcode, CurByte, OS); >>>>>>>>>>>> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 >>>>>>>>>>>> EmitRegModRMByte(MI.getOperand(CurOp), >>>>>>>>>>>> GetX86RegNum(MI.getOperand(...

...etermineREX(MI); > + unsigned REX = X86InstrInfo::determineREX(MI); > if (REX) > MCE.emitByte(0x40 | REX); > } > @@ -632,7 +497,7 @@ > case X86::MOVPC32r: { > // This emits the "call" portion of this pseudo instruction. > MCE.emitByte(BaseOpcode); > - emitConstant(0, sizeOfImm(Desc)); > + emitConstant(0, X86InstrInfo::sizeOfImm(Desc)); > // Remember PIC base. > PICBaseOffset = MCE.getCurrentPCOffset(); > X86JITInfo *JTI = dynamic_cast<X86JITInfo*>(TM.getJITInfo()); > @@ -657,7 +522,7 @@ &...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And