[LLVMdev] Distinguish variadic register defines/uses in MCInstrDesc?

[Christoph Grenz]

Hallo,

I worked on how to handle the distinction between variadic defines and uses 
and my current solution is this:

I introduce a new dag item in Instruction called VariadicOperandList, which by 
default is undefined. It keeps a marker variable_* and all operands which are 
placeholders for variable lists (like 'reglist' on ARM).

I think it's the cleanest solution to keep them in a seperate dag, because 
else either register defines would be in the 'ins' list or the parser would 
become much more complex to change the order of operands to get the variable 
items in 'outs' to the end of the list.

I appended my current patches.

At the moment two tests fail.
2011-06-16-TailCallByVal.ll because an instruction alias for a variadic 
instruction isn't recognized and thumb2-ldm.ll fails with "Trying to add an 
operand to a machine instr that is already done!"

Any comments?

Thanks,
Christoph Grenz

Am Donnerstag, 27. September 2012, 01:42:04 schrieb Christoph Grenz:
> Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen:
> > Hi Christoph,
> > 
> > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and
> > defs. Since variadic instructions will always require some kind of special
> > handling, it doesn't seem worthwhile to make the model more detailed.
> 
> I don't see what makes them so different from other instructions.
> MCInstrDesc 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. Only the third case really needs
> special handling and I couldn't find an instruction that falls into this
> case.
> > I think your current workaround sounds fine.
> > 
> > /jakob
> 
> Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: variable_ops.diff
Type: text/x-patch
Size: 10548 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/35d3c27c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: variable_ops_arm.diff
Type: text/x-patch
Size: 13431 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/35d3c27c/attachment-0001.bin>