[PATCH] Add support for ARM modified immediate syntax

[Mihail Popa]

Is there any proper documentation for what ComplexPatterns do and how they
interact with
the rest of the descriptions in the td file? Surprisingly, Google is not my
friend today.

Specifically why do I get error in pattern definitions once I add
MIOperandInfo? Ex:

/home/mihpop01/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td:3227:1: error: In
anonymous.377: Instruction 'SUBri' expects more operands than were provided.
def : ARMPat<(add     GPR:$src, so_imm_neg:$imm),

Also why do I get error for move instruction definitions only? Eg:

/home/mihpop01/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td:3523:1: error: In
MVNi: Instruction 'MVNi' expects more operands than were provided.
def  MVNi  : AsI1<0b1111, (outs GPR:$Rd), (ins so_imm:$imm), DPFrm,
^

What I find bewildering is that the other instructions definitions are
accepted. Is
there anything special about moves?

If you can point me to any documentation which explains these things
satisfactorily, I'd be much in debt.

Leaving implementation details aside and if I my intuition serves me right,
then the following should be true:

1. i can have the selector produce two int32 MachineOperands via a
selection pattern
2. the two int32 MachineOperands will be automatically lowered to MCOperands
3. the instructions accepting this kind of operand will still have only one
$imm in the syntax string
4. the custom parser will parse the string and generate to immediate
MCOperands
5. all methods which manipulate operands of this type need to read TWO
operands instead of one.
(which I have seen done before and I find rather peculiar -- it really only
works when this operand is
the last one).

But here is the problem: since this kind of immediate may be affected by
fixups, it will be potentially
modified outside the encoder/decoder/printer/render methods which are tied
to the operand class.
Thus I actually need to know based on an opcode:

a. that an instruction even accepts am SOImm and not a normal imm
b. (ideally) which operand is the first of the two... now you may point out
that modified immediates
come always last, but relying on that seems really dirty.

Regards,
Mihai




On Tue, Aug 13, 2013 at 2:02 PM, Tim Northover <t.p.northover at gmail.com>wrote:

> Hi Mihai,
>
> On 13 August 2013 13:40, Mihail Popa <mihail.popa at gmail.com> wrote:
> >> Incidentally, adding an "MIOperandInfo = (ops i32imm:$value,
> i32imm:$rot)"
> >> would probably make the internal representation neatest here. by giving
> your
> >> MachineInstr two separate operands for the
> >> immediate value.
> >
> > Not so sure how this can help with anything since the natural
> representation
> > of an integer is ... well, one integer.
>
> But you've got the problem that there are multiple encodings for the
> integer 0 (for example). You could squash them into one MCOperand as
> (say) "BaseImm | (RotAmt << 8)", but splitting them into two
> MCOperands strikes me as more accurate.
>
> > I am not sure I understand how you could have the instruction selector
> > produce two operands instead of one.
>
> That's what ComplexPatterns do, provided the extra operands are hidden
> in an MIOperandInfo. For example
>
> def so_imm : Operand<i32>, ComplexPattern<i32, 2, "SelectSOImm"> {
>   let MIOperandInfo = (ops i32imm:$value, i32imm:$rot);
>   [...]
> }
>
> lets you write patterns like "(set GPR:$Rd, (add GPR:$Rn,
> so_imm:$imm))". The function "SelectSOImm" would get called with two
> "SDValue &" operands that it's expected fill up based on its input
> node if it succeeds.
>
> > In addition there would still have to be a further lowering pass when the
> > MCOperand is generated.
>
> That's all handled automatically, if I understand you correctly. Both
> the MachineInstr and the MCInst would have two immediate operands.
>
> > Speaking of which - looking at how MachineOperands are lowered to
> > MCOperands: how can I tell that a specific
> > MachineOperand::MO_Immediate will actually end up being an ARMSOImm? The
> > MCOperandInfo structures don't help.
>
> I don't believe you can. Why do you think you need to?
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130813/72332ebe/attachment.html>