[PATCH] Add support for ARM modified immediate syntax

Mihail Popa mihail.popa at gmail.com
Tue Jul 30 02:35:01 PDT 2013


Guys,

I'm either not getting my point across or I'm missing something.
This is not a simple matter of accepting a different syntax or an alias for
another "canonical" syntax.

There is no canonical syntax. There still is one syntactic representation
for each bit-pattern. There is
no ambiguity,

For each pair of integers there is only one encoding. For each encoding
there is only one pair of integers.
The problem is that the actual number these bits/numbers stand for can be
represented in multiple ways.

You can't just parse (#a, #b) and decode it as the immediate "1". There are
multiple (a, b) pairs which have
the meaning of "1" and which lead to different encodings.

So what I see is two solutions:

1. have parse-only instruction definitions which pipe the values #a and #b
straight into their respective places
in the instruction word (the proposed solution)
2. a combination of:

   - adding a new type of custom parser which parses #a, #b as one integer
   but keeping in mind that #b is optional and zero if left out (which I doubt
   is feasible within the constraints of what tablegen generates. That is not
   a parser by any means - just a rather dumb string matcher)
   - changing the internal representation of immediates to a value/modifier
   pair
   - changing the emission of affected instructions
   - changing the lowering towards MC

What I have to solve is essentially an assembly syntax problem which needs
resolution for tools/core validation purposes.
While I appreciate that "2" is a cleaner solution, isn't it a bit much to
complex and risky to do? A bug in solution 1
will only be confined to the use of the new instructions. A bug in solution
2 will impact any compilation.

I think a good principle of taking decisions is comparing the scope of a
change to the scope of it's potential impact.
While with 1 the scopes are similar (assembler-only functionality confined
to specific instructions), solution 2 exhibits
a pretty large imbalance in this regard (the scope of the change is
assembler-only functionality specific to a few instructions,
the scope of the potential impact is any compiled application).

I am curious as to the groups view on the previous paragraph. This is the
main reason I chose a copy-paste-y solution
(that and the fact that tablegen does not support certain features).

Regards,
Mihai


On Mon, Jul 29, 2013 at 10:41 PM, Renato Golin <renato.golin at linaro.org>wrote:

> On 29 July 2013 20:55, Jim Grosbach <grosbach at apple.com> wrote:
>
>> +1. This is very important. The MCInst should not have any memory of what
>> the assembly syntax form was.
>>
>
> Agreed. Consistency in the representation, not in the notation.
>
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130730/7c61fe00/attachment.html>


More information about the llvm-commits mailing list