[PATCH] Add support for ARM modified immediate syntax

[Mihail Popa]

FWIW, the bitwise representation is less of an issue as it preserves the an
essential property
of an integer - that of being one integer :)

Since it's quite a basic assumption people make without noticing they do
it, it's far less likely
to cause any problems down the pipe than a pair representation.

The difficulty is knowing at MachineOperand lowering whether an immediate
should be encoded
straight or in the value + rot pair.

Regards,
Mihai


On Tue, Aug 13, 2013 at 2:36 PM, Mihail Popa <mihail.popa at gmail.com> wrote:

> 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/5f2ac511/attachment.html>