[LLVMdev] Instruction with variable number of outputs

Chris Lattner clattner at apple.com
Mon Mar 22 16:28:35 PDT 2010


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_ops", those are really output registers, the registers being loaded.

Ah, gotcha.  LDM is a particularly evil instruction to model.  I agree it is best to model them as a variable number of outputs.

> I am assuming that the operands on a machine instruction are, in order: fixed outs, fixed ins, variable ops, implicit ops. The variable ops can be inputs or outputs.
> 
> As far as I can tell, this is only a problem with verification. The operand corresponding to $dsts is a <def>, but the TargetInstrDesc says that it is one of the fixed inputs. The following 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.

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 need a way of describing the LDM instruction with:
> 
> Fixed outputs: none
> Fixed inputs: addr and pred
> Variable ops: list of output registers

I would prefer to spell this as:

def LDM : AXI4ld<(outs reglist:$dsts), (ins addrmode4:$addr, pred:$p),

Would this work?  You could change 'reglist' to have one fixed operand and the rest variable?  There is no reason to support the 'no output' form of reglist.

-Chris



More information about the llvm-dev mailing list