search for: variable_op

...load multiple instruction looks like: // A list of registers separated by comma. Used by load/store multiple. def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts, variable_ops), IndexModeNone, LdStMulFrm, IIC_iLoadm, "ldm${addr:submode}${p}\t$addr, $dsts", "", []>; Tablegen produces an instruction description with 5 input operands: 2 for $addr, 2 for $p, and 1 for $dsts. But $dsts and the following variable_ops a...

...> > // A list of registers separated by comma. Used by load/store multiple. > def reglist : Operand<i32> { > let PrintMethod = "printRegisterList"; > } > > def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, > reglist:$dsts, variable_ops), > IndexModeNone, LdStMulFrm, IIC_iLoadm, > "ldm${addr:submode}${p}\t$addr, $dsts", "", []>; > > Tablegen produces an instruction description Ok, you mean TargetInstrDesc, right? > with 5 input operands: 2 for $addr, 2 for $...

...f registers separated by comma. Used by load/store multiple. >> def reglist : Operand<i32> { >> let PrintMethod = "printRegisterList"; >> } >> >> def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, >> reglist:$dsts, variable_ops), >> IndexModeNone, LdStMulFrm, IIC_iLoadm, >> "ldm${addr:submode}${p}\t$addr, $dsts", "", []>; >> >> Tablegen produces an instruction description > > Ok, you mean TargetInstrDesc, right? Yes. >> with 5 in...

variable_ops is used in the tablegen defs for many targets to denote instructions that a variable number of inputs, but it seems that there aren't any targets for which this results in variable elements in the instruction encoding (and thus in assembler parsing), since the tablegen generated assembly match...

On Mar 19, 2010, at 11:04 AM, Jakob Stoklund Olesen wrote: >>> The description should only have 4 operands + variable_ops. >>> >>> How can you specify a named, variable list of output operands? >> >> Why do you need to do this? You currently can't do it. > > Because an instruction like LDM loads a variable number of registers. When it specifies "reglist:$dsts, variable...

Hi Micah, the register use list gets dropped by the instruction selector because you didn't specify "variable_ops" in the input operand list of your CALL instruction. It has to look like this: (ins calltarget:$dst, variable_ops) Regards, Christoph

.../12 12:14, Paul Shortis wrote: > Thanks Richard, > > You're correct, they are similar. In the XCoreInstrInfo.td patterns > what I'm struggling with is why this .... > > def BL_lu10 : _FLU10< > (outs), > (ins calltarget:$target, variable_ops), > "bl $target", > [(XCoreBranchLink immU20:$target)]>; > > def : Pat<(XCoreBranchLink tglobaladdr:$addr), (BL_lu10 > tglobaladdr:$addr)>; > def : Pat<(XCoreBranchLink texternalsym:$addr), (BL_lu10 > texternalsym:$ad...

...trDesc provides the information which operands are defines and which uses for all other instruction types and for variadic there are only three possible cases: * All variadic registers are uses (push/stm on ARM) * All variadic registers are defines (pop/ldm) * uses and defines are mixed. I think variable_ops on x86 RET can also be modeled as the first case. The first two cases don't need any special handling. The start and count of variadic operands is known through MCInstrDesc and MCInstruction::getNumOperands(). So I can handle them like any other instruction if I know which case applies. On...

...definitions and uses to track all instructions the branch depends on. This works well for most cases, except if there are Thumb pop instructions involved. Pop has a variable number of output registers, so MCInstrDesc::getNumDefs returns zero and, as far as I can see, in the tablegen files 'variable_ops' is always in the 'ins' list and MCInstrDesc only provides isVariadic(); My current workaround is to assume that all variadic arguments of instructions that have zero register definitions but are marked as mayLoad are register definitions. I'm not very happy with this solution....

...t; http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > Thanks Richard, You're correct, they are similar. In the XCoreInstrInfo.td patterns what I'm struggling with is why this .... def BL_lu10 : _FLU10< (outs), (ins calltarget:$target, variable_ops), "bl $target", [(XCoreBranchLink immU20:$target)]>; def : Pat<(XCoreBranchLink tglobaladdr:$addr), (BL_lu10 tglobaladdr:$addr)>; def : Pat<(XCoreBranchLink texternalsym:$addr), (BL_lu10 texternalsym:$addr)>; is necessary. Are the P...

...hich operands are defines and which > uses for all other instruction types and for variadic there are only three > possible cases: > * All variadic registers are uses (push/stm on ARM) > * All variadic registers are defines (pop/ldm) > * uses and defines are mixed. > > I think variable_ops on x86 RET can also be modeled as the first case. > > The first two cases don't need any special handling. The start and count of > variadic operands is known through MCInstrDesc and > MCInstruction::getNumOperands(). So I can handle them like any other > instruction if I know...

....isMachoABI()) { I = Defs_Macho + (sizeof(Defs_Macho)/sizeof(unsigned)); } else { I = Defs_ELF + (sizeof(Defs_ELF)/sizeof(unsigned)); } return I; } }] in { // Convenient aliases for call instructions def BL : IForm<18, 0, 1, (ops calltarget:$func, variable_ops), "bl $func", BrB, []>; // See Pat patterns below. def BLA : IForm<18, 1, 1, (ops aaddr:$func, variable_ops), "bla $func", BrB, [(PPCcall (i32 imm:$func))]>; def BCTRL : XLForm_2_ext<19, 528, 20, 0, 1, (o...

...lag.Val) Ops.push_back(InFlag); Chain = DAG.getNode(CallOpc, NodeTys, &Ops[0], Ops.size()); This creates a call node with a list of input registers, these are marked as uses. In the PPC backend, this is matched with this pattern: ... def BLA : IForm<18, 1, 1, (ops aaddr:$func, variable_ops), "bla $func", BrB, [(PPCcall (i32 imm:$func))]>; ... The "variable_ops" part of the operation list causes all those registers to be added to the node when the isel turns the isel graph into the sched graph. Unfortunately, this will not work...

..., timm:$amt2)]>; def ADJCALLSTACKUP : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), [(MyCallseqEnd timm:$amt1, timm:$amt2)]>; } def Custom_CALL : Pseudo<(outs), (ins IRF32:$target, variable_ops), [(my_call IRF32:$target)]> { let isCall = 1; let usesCustomInserter = 1; } def Custom_RETURN : Pseudo<(outs), (ins variable_ops), [(my_ret)]> { let isReturn = 1; let usesCustomInserter...

Hi, I've been hitting my head to wall two days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [],

Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers

...s_Macho)/sizeof(unsigned)); > } else { > I = Defs_ELF + (sizeof(Defs_ELF)/sizeof(unsigned)); > } > > return I; > } > }] > > in { > // Convenient aliases for call instructions > def BL : IForm<18, 0, 1, (ops calltarget:$func, variable_ops), > "bl $func", BrB, []>; // See Pat patterns > below. > def BLA : IForm<18, 1, 1, (ops aaddr:$func, variable_ops), > "bla $func", BrB, [(PPCcall (i32 imm: > $func))]>; > def BCTRL : XLForm...

On Sep 24, 2012, at 6:39 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Is it possible to extend LLVM to check if 'variable_ops' is in 'ins' and/or > 'outs' in tablegen, so that MCInstrDesc could provide something like > hasVariadicDefs() and hasVariadicUses()? > > That way handling variadic instructions when disassembling would be much > easier and only instructions with variadic use...

Hi, it looks like old-style code generators can no longer work with LLVM CVS, because: 1. The TableGen uses the DAG from instruction to computed the number of operands written in generated tables, and when there's no DAG, writes 0. 2. MachineInstructions::addRegOperand checks for maximum number of operands. So, when not using DAGS in TableGen input, addRegOperand asserts on adding the very

Hello. I am making a LLVM backend for a new architecture XCC. During implementation of instructions for XCC, I found that there are instructions need more than 3 operands in the target language manual. I could implement insructions need 1, 2 or 3 operands thanks to the examples in the LLVM backends already offered by you guys. But, I am not sure about those kind of instructions needs many number