[PATCH] Add support for ARM modified immediate syntax

[Mihail Popa]

I'm looking for a more agreeable solution to this, but I'm hitting issues.
Two ways I can see this done:

1. instructions keep a single immediate operand so_imm which is parsed with
a custom parser method. Basically the asm pattern remains "asm $reg1,
$reg2, $imm"
and it's supposed to match strings like "asm r0, r1, #4, #6". I don't think
this is possible
due to the operation of the parser. It will recognize a 3 operand pattern
and will not attempt
to match it against a 4 operand assembly string.

2. instructions will have two immediate operands, with an alias to support
the single immediate
operand plus one conversion function to even out the representation (i.e.
to transform the
single operand into <value, rot> pair. There are issues with this one as
well. For one thing,
not all 16-bit immediates can be represented and tablegen lacks the ability
to use additional
predicates when matching instruction aliases (i.e. I can't have a special
predicate to decide
whether an alias can apply). Secondly, even if this is fixed, there remains
the problem of
the codegen pattern. The selection IR contains a single immediate. If the
instruction has two
immediate operands, the pattern becomes illegal or can't be matched.

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.

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.

It looks to me that there really isn't much alternative to having separate
instructions.
What do you think? Is there anything I'm overlooking?

Regards,
Mihai


On Thu, Aug 1, 2013 at 7:52 PM, Tim Northover <t.p.northover at gmail.com>wrote:

> > There are two different issues that were brought up:
> >
> > 1. whether this support should be implemented in the first place
>
> I don't think anyone's argued that the syntax shouldn't be supported.
> It's definitely a good idea, and a necessity if we claim to be a full
> ARM assembler.
>
> > 2. the exact manner of implementation
>
> That's where the disagreements are, I think.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130809/233d0e4d/attachment.html>