[PATCH] Add support for ARM modified immediate syntax

[Mihail Popa]

Tim,

> This is because of the predicate and flag-setting operands (usually
> imm:14 and reg:0)? If so, couldn't you count from the back rather than
> the front of the list? Or is there some even more evil mangling going
> on?

I tried counting from the top and from the bottom and there doesn't seem
to be any viable general approach. I'll look into it in more detail
tomorrow.

> We may need an umpire soon (or pistols at dawn?). I took a stab at the
> one-instruction-to-rule-them-all approach (in the MC layer so far)
> over the weekend

Good for you. To be clear, I have nothing against the unified representation
as long as the changes are confined to the MC layer. If this affects any
layer
above, it's wrong to do it.

Mihai


On Mon, Aug 19, 2013 at 5:43 PM, Tim Northover <t.p.northover at gmail.com>wrote:

> Hi Mihai,
>
> > I found a way to avoid having a big switch that converts opcodes between
> ri
> > and rii. Basically, I am assigning all the rii instructions to a new
> > DecoderNamespace.
>
> Hmm. Interesting approach.
>
> We may need an umpire soon (or pistols at dawn?). I took a stab at the
> one-instruction-to-rule-them-all approach (in the MC layer so far)
> over the weekend: http://llvm-reviews.chandlerc.com/D1432
>
> > Now, surprisingly I am having problems with step 1!
> > Although the two immediates are always the final inputs, they are not the
> > final MCOperands, nor the final immediate MCOperands.
>
> This is because of the predicate and flag-setting operands (usually
> imm:14 and reg:0)? If so, couldn't you count from the back rather than
> the front of the list? Or is there some even more evil mangling going
> on?
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/e8adb790/attachment.html>