search for: mioperandinfo

What does MIOperandInfo exactly mean while defining an Operand class? e.g. here class X86MemOperand<string printMethod> : Operand<iPTR> { let PrintMethod = printMethod; let MIOperandInfo = (ops ptr_rc, i8imm, ptr_rc, i32imm); } -------------- next part -------------- An HTML attachment was scrubbed... UR...

...g> Pattern = [(set ROWD:$wd, (TyNode (OpNode Addr:$addrsrc)))]; InstrItinClass Itinerary = itin; string DecoderMethod = "DecodeMSA128Mem"; } class LD_D_DESC : LD_DESC_BASE<"ldvd", load, v32i16, MSA128DOpnd>; I've tried to change mem_msa to hold only let MIOperandInfo = (ops simm10) but there are problems it seems: // MSA specific address operand def mem_msa : mem_generic { let MIOperandInfo = (ops ptr_rc, simm10); let EncoderMethod = "getMSAMemEncoding"; } Could you please tell me what is the simplest way to define in LD_DESC_BASE a $addrsrc...

...lar to yours (the 16-bit offset is sign-extended though): // Memory address: 32-bit base register + 16-bit offset register def ADDRrr : ComplexPattern<iPTR, 2, "SelectADDRrr", []>; def MEMrr : Operand<iPTR> { let PrintMethod = "printMemOffsetOperand"; let MIOperandInfo = (ops RC32, RC16_l); } but it is still happy to select for offset’s > 16-bits. There is something I am just not yet getting right, but it looks like I am on the right track. All the best, MartinO From: Steve Montgomery [mailto:stephen.montgomery3 at btinternet.com]...

...of stwu should get matched with the given pre_store. But I am confused as to how "ptroff" and "ptrreg" get matched with "memri" used in STWU? For reference[1] memri is defined as: def memri :Operand<iPTR> { let PrintMethod = "printMemRegImm"; let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); let EncoderMethod = "getMemRIEncoding";} [1] https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.td?view=markup -- * Anitha* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://li...

...ate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat pre_store" get matched with those of memri. It is defined with operand types as: let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); while Pat is defined as: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; So now how iPTR:$ptrreg and iaddroff:$ptroff get matched with ptr_rc_nor0:$reg and dispRI:$imm respectively?...

...ng operands are fine as they fall in the variable_ops part of the instruction. I need a way of referring to the variable_ops by name without forcing the first operand to be an input. >> def reglist : Operand<i32> { >> let PrintMethod = "printRegisterList"; >> let MIOperandInfo = (ops variable_ops); >> } >> >> def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts), This syntax is not ideal, because reglist:$dsts is a variable list of output operands. But at least there is no extra input operand. I need a way of describing the LDM in...

...lar to yours (the 16-bit offset is sign-extended though): // Memory address: 32-bit base register + 16-bit offset register def ADDRrr : ComplexPattern<iPTR, 2, "SelectADDRrr", []>; def MEMrr : Operand<iPTR> { let PrintMethod = "printMemOffsetOperand"; let MIOperandInfo = (ops RC32, RC16_l); } but it is still happy to select for offset’s > 16-bits. There is something I am just not yet getting right, but it looks like I am on the right track. I believe that the MIOperandInfo will constrain the register class for your 16-bit offset operand to RC16_1 but...

...y fall in the variable_ops part of the instruction. > > I need a way of referring to the variable_ops by name without forcing the first operand to be an input. Ok. >>> def reglist : Operand<i32> { >>> let PrintMethod = "printRegisterList"; >>> let MIOperandInfo = (ops variable_ops); >>> } >>> >>> def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts), > > This syntax is not ideal, because reglist:$dsts is a variable list of output operands. But at least there is no extra input operand. > > I nee...

...EISelLowering.cpp for MIPS). The relevant code for MIPS is in addMSAIntType() and addMSAFloatType() and makes the vector types legal by binding them to a register class and specifies how to handle each operation using setOperationAction(). > I've tried to change mem_msa to hold only let MIOperandInfo = (ops > simm10) but there It sounds like you're on the right track but there may be an easier way. Continuing on this track, I believe you will also need to change the addrimm10 mentioned in the argument list for LD_DESC_BASE. The one for MIPS will be matching the DAG using the selectIntAd...

...t{15-8}; let Inst{15} = 0b1; let Inst{14-13} = 0b00; let Inst{12-8} = 0b01101; let Inst{7-0} = opcode; } and I have def pcoffset8 : Operand<i8>, ImmLeaf<i8, [{ return Immediate >= -128 && Immediate <= 127; }]> { let PrintMethod = "printPCRelImmOperand"; let MIOperandInfo = (ops i8imm); let ParserMatchClass = ImmediateAsmOperand<"Imm8">; let EncoderMethod = "getMemOpValue"; let DecoderMethod = "DecodeMemOperand"; } def pcoffset16 : Operand<i16>, ImmLeaf<i16, [{ return Immediate >= -32768 && Immediate &lt...

...d addPointerRegClass() to my InstrInfo class The compiler generates the some code as before, but that seems to be ok, because I haven't used ptr_rc yet. 4) I changed the address mode MEMri: def MEMri : Operand<iPTR> { let PrintMethod = "printMemOperand"; // was: let MIOperandInfo = (ops IntRegs, i32imm); let MIOperandInfo = (ops ptr_rc, i32imm); } for the C code int c; void f(void) { c = 4711; } I get the error message: Register class of operand and regclass of use don't agree! Operand = 0 Op->Val = 0x42b08d60: i32 = SETHIi 0x42b08d00 MI = STri %reg1026...

...tore. But I am confused as to how > "ptroff" and "ptrreg" get matched with "memri" used in STWU? > > > For reference[1] memri is defined as: > > def memri :Operand<iPTR> { > > let PrintMethod = "printMemRegImm"; > > let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); > > let EncoderMethod = "getMemRIEncoding"; > > } > > [1] > https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.td?view=markup > -- > /* Anitha*/ > > > _______________________________...

...mb2 target by doing the following few changes: 1) declare a PTRRC regclass in ARMRegisterInfo.td with only one physreg: def PTRRC : RegisterClass<"ARM", [i32], 32, (add R6)>; 2) modify the RC used in the addr_offset_none addressing mode in ARMInstrInfo.td around line 947 to: let MIOperandInfo = (ops PTRRC:$base); (this is used by the t2LDR_POST instruction) 3) and likewise modify the t2addrmode_imm12 addressing mode in ARMInstrThumb2.td around line 151 to: let MIOperandInfo = (ops PTRRC:$base, i32imm:$offsimm); (used by the load/store instructions) then compile with -O3 and done :) I...

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a pr...

I have a rudimentary implementation for load and store instructions, where the memory address operand is automatically post-incremented when the load or store instruction is issued. However, this is currently coded using custom lowering, and explicit pattern matching in the 'ISelDAGtoDAG' implementation. But it seems to me that I ought to be able to achieve this exclusively using

I'm attempting to implement codegen support for the AVR ST/LD <http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_ST.html> family of instructions. The binary encoding is not particularly consistent -- take a look at this table of variants of LD, along with their machine code representation: # load 8 bits from pointer register X into general purpose Rd ld Rd, X `1001 000d dddd

...the following variable_ops are all outputs! The description should only have 4 operands + variable_ops. How can you specify a named, variable list of output operands? Perhaps this could be made to work: def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; let MIOperandInfo = (ops variable_ops); } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts),

...en, but I have been unsuccessful so far. Here is an example of something I have tried. It fails to compile with tablegen, but I hope it can help demonstrate what I am trying to do: def F32Node : PatLeaf<(vt), [{return N->getVT() == MVT::f32;}]>; def F32Op : Operand <f32> { let MIOperandInfo = (ops GPR, f32imm); } def ADD : InstAMD < (outs GPR:$dst), (ins F32Op:$src0, F32Op:$src1), "ADD $dst, $src0, $src1"), [(set GPR:$dst, (fadd F32Node:$src0, F32Node:$src1))] >; Is what I am trying to do possible with tablegen, and if so wh...

...mem:LD4[%uglygep10], mem:LD4[%uglygep2021] If I had to guess, I would think it's because of how LDR is defined: def addrmodepc : Operand<i32>, ComplexPattern<i32, 2, "SelectAddrModePC", []> { let PrintMethod = "printAddrModePCOperand"; let MIOperandInfo = (ops GPR, i32imm); } def LDR : AI2ldw<(outs GPR:$dst), (ins addrmode2:$addr), LdFrm, IIC_iLoadr, "ldr", "\t$dst, $addr", [(set GPR:$dst, (load addrmode2:$addr))]>; It's using addrmodepc, which is a ComplexPattern. The TableGen code can...

I can't get it to work with pattern matching. My operand is defined like so: def LDSTPtrReg : Operand<i16> { let MIOperandInfo = (ops PTRREGS); let EncoderMethod = "encodeLDSTPtrReg"; } I am able to use it in the place of PTRREGS in the definition of the LD instruction, but if I use it in an instruction matching pattern, compilation fails with the error "Unknown leaf kind: LDSTPtrReg:i16:$ptrreg"....