[PATCH] Add support for ARM modified immediate syntax

[Mihail Popa]

Also isn't a bitwise representation closer to the "policy" of representing
operands as close
to the encoding as possible?

Surely representing a floating point as a <sign, mantissa, exp> isn't any
more accurate.
Additionally, it does not matter which encoding gets generated for selected
code.
I only need to preserve the exact representation for assembled code...

Mihai


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

> 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/3a5a7831/attachment.html>