[PATCH] Add support for ARM modified immediate syntax

Mihail Popa mihail.popa at gmail.com
Tue Aug 13 05:40:41 PDT 2013


> 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.
I am not sure I understand how you could have the instruction selector
produce two operands instead of one.
In addition there would still have to be a further lowering pass when the
MCOperand is generated.

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.
The operand type is only set for the out-of-the-box types, not for the
custom types. Any ideas how I can detect a particular
operand of a particular instruction is of a particular operand class?
(without dumb-coding it, of course).

Regards,
Mihai


On Fri, Aug 9, 2013 at 1:42 PM, Tim Northover <tnorthover at apple.com> wrote:

> Hi Mihai,
>
> > For solution 1, the blocking issue is the parser recognizing comma as a
> operand separator
> > and not matching patterns and assembly strings of different arity.
>
> I think if you give your so_imm a ParserMethod then it short-circuits the
> normal comma-spotting, and it can eat as much of the string as it likes.
> This is how the addresses are matched, for example: even though "[r0, #3]"
> has a comma in it, the generic code doesn't see it.
>
> 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.
>
> Because the two operands would be hidden behind the single so_imm it
> should be reasonably easy for a ComplexPattern to match them still.
>
> > For solution 2, the blocking issue is the selection patterns. Basically
> I'd have to have a separate
> > set on instructions for selection only, which makes the whole effort
> futile.
>
> Yes, I think that goes wrong rather quickly. I can't think of a sensible
> way to match those instructions.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130813/52f77181/attachment.html>


More information about the llvm-commits mailing list