search for: operandtype

...t for PrintMethod, effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why simm16 matches and uimm16 does not. Here is the pattern if that helps at all. So just as a reference: def simm16 : Operand<i16> { let DecoderMethod= "DecodeSimm16"; let OperandType = "OPERAND_IMMEDIATE"; } def uimm16 : Operand<i16> { let PrintMethod = "printUnsignedImm"; let OperandType = "OPERAND_IMMEDIATE"; } def immSExt16x : ImmLeaf<i16, [{ return isInt<16>(Imm); }]>; def immZExt16x : ImmLeaf<i16, [{ return isUI...

...let Inst{31-23} = opcode; let Inst{26-11} = s16; } class REP_1R_DESC_BASE<, InstrItinClass itin = NoItinerary> { dag OutOperandList = (outs); /* From include/llvm/Target/Target.td: let OperandType = "OPERAND_IMMEDIATE" in { ... def i64imm : Operand<i64>; */ dag InOperandList = (ins i64imm:$imm); string AsmString = "REPEAT_X_TIMES($imm"; list<dag> Pattern = [(int_repeat_x_times i64imm:$imm)];...

...unclear >> why >> simm16 matches and uimm16 does not. Here is the pattern if that helps >> at >> all. >> >> So just as a reference: >> >> def simm16 : Operand<i16> { >> let DecoderMethod= "DecodeSimm16"; >> let OperandType = "OPERAND_IMMEDIATE"; >> } >> >> def uimm16 : Operand<i16> { >> let PrintMethod = "printUnsignedImm"; >> let OperandType = "OPERAND_IMMEDIATE"; >> } >> >> def immSExt16x : ImmLeaf<i16, [{ return isInt...

Matt, so in AMDGPU, the operands are sort of 'generic'? Can you point me to the right places? Thanks. On Wed, Apr 12, 2017 at 1:36 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 04/12/2017 10:25 AM, Ryan Taylor via llvm-dev wrote: > > For example, given a multiclass for ADD 32 bit that might produce > something like: > > ADD32_REG_REG_REG

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint

Thanks for your reply. We are propagating sign info to tablegen currently using BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation). I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000? Thanks. On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at

On 29 nov 2010 03:47 "Xu Zhongxing" <xuzhongxing at gmail.com> wrote: > Hi, > I enjoyed the new coding style in recent patches. Camel case makes it > easy to pick a descriptive name. Starting functions and variables with > lower cases reduces chances to conflict with a type name. On the other hand, having names that only differ in the case of a single character, is not

...uts), (ins GR32:$ra, brtarget:$offset), "bgeid\t$ra,$offset", [], IIC_BRc> {* * let rd = 0b10101;* *}* *def brtarget : Operand<OtherVT>* *{* * let PrintMethod = "printPCRelImmOperand";* * let EncoderMethod = "getBranchTargetOpValue";* * let OperandType = "OPERAND_PCREL";* * let DecoderMethod = "DecodeBranchTarget";* *}* *getBranchTargetOpValue**(const MCInst &MI, unsigned OpNo,* * SmallVectorImpl<MCFixup> &Fixups,* * const MCSubtargetInfo &STI) const {*...

...TInstrInfo.td file. Currently I have done the following: in TARGETRegisterInfo.td file I have defined the registers: MYREG1_NAME and MYREG2_NAME in TARGETInstrInfo.td file I have the following definitions: def simm16 : Operand<i16> { let DecoderMethod= "DecodeSimm16"; let OperandType = "OPERAND_IMMEDIATE"; } class SII<bits&lt;6> op, string instr_asm, Operand Imm> : FI<op, (outs), (ins Imm:$val), !strconcat(instr_asm, &quot;\t$val&quot;), [], IIAlu> { let rs = 0; let rt = 0; } def MOV : SII<0x21, "mov", simm16&...

...t;printMemOperand";   let MIOperandInfo = (ops ptr_rc, ptr_rc, simm16); ^-- for two registers   let EncoderMethod = "getGSMemEncoding";                                             ^-- just encoding two registers and one offset   let ParserMatchClass = MipsMemAsmOperand;   let OperandType = "OPERAND_MEMORY"; } ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- I couldn't fool llvm-mc :) test/MC/Mips/loongson3a/valid.s:32:30: error: invalid operand for instruction         gslbx           $2,0($3,$4)                          ...

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those

...like in the following complete specification: // Inspired heavily from lib/Target/X86/X86InstrInfo.td class X86MemOperand<string printMethod> : Operand<iPTR> { let PrintMethod = printMethod; let MIOperandInfo = (ops i8imm, i32imm); let OperandType = "OPERAND_MEMORY"; } // Gather mem operands class X86VMemOperand<RegisterClass RC, string printMethod> : X86MemOperand<printMethod> { let MIOperandInfo = (ops i8imm, RC, i32imm); } def vx256xmem : X86VMemOpe...

Hi, I enjoyed the new coding style in recent patches. Camel case makes it easy to pick a descriptive name. Starting functions and variables with lower cases reduces chances to conflict with a type name. 2010/11/23 Zhanyong Wan (λx.x x) <wan at google.com> > On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: > > +llvmdev > > >

...r opportunities to use the LLVM small container classes. For instance, the "fOperands" ivar in RecognizableInsn. 8. While we're on that, please use "Instruction" or "Instr" instead of "Insn" for consistency's sake. 9. You have types called "operandType_t", etc. We normally don't use the "_t" suffix for types. Perhaps renaming them. 10. In the "static inline bool outranks(instructionContext_t upper, instructionContext_t lower)", it would be good to assert that upper and lower are strictly less than IC_max. 11....

[ This question has already been asked in lldb-dev (see attached emails), however it was suggested that I should forward the question to llvm-dev, since it is more relevant to MC Disassembler than LLDB. ] Hello, I am looking for a way to track memory stores and save both the old and the new value of the memory location being modified using LLDB, as described below: 1. Recognize the

Dear mailing list: the attached diff implements a table-driven disassembler for the X86 architecture (16-, 32-, and 64-bit incarnations), integrated into the MC framework. The disassembler is table-driven, using a custom TableGen backend to generate hierarchical tables optimized for fast decode. The disassembler consumes MemoryObjects and produces arrays of MCInsts, adhering to the

...ng complete specification: > // Inspired heavily from lib/Target/X86/X86InstrInfo.td > class X86MemOperand<string printMethod> : Operand<iPTR> { > let PrintMethod = printMethod; > let MIOperandInfo = (ops i8imm, i32imm); > let OperandType = "OPERAND_MEMORY"; > } > // Gather mem operands > class X86VMemOperand<RegisterClass RC, string printMethod> > : X86MemOperand<printMethod> { > let MIOperandInfo = (ops i8imm, RC, i32imm); > } >...

Hello. Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have to say that the definition of the "multiclass avx512_gather" from lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it. I currently have some serious problems with TableGen - it gives an assertion failure:

...y created. It is always set to point to CodeGenInstruction::OperandList. > 8. While we're on that, please use "Instruction" or "Instr" instead > of "Insn" for consistency's sake. Fixed. Thanks for the heads-up. > 9. You have types called "operandType_t", etc. We normally don't use > the "_t" suffix for types. Perhaps renaming them. Fixed. Now for example operandType_t is OperandType. > 10. In the "static inline bool outranks(instructionContext_t upper, > instructionContext_t lower)", it would be good...