[PATCH] Add support for ARM modified immediate syntax

Tim Northover t.p.northover at gmail.com
Thu Aug 15 02:16:44 PDT 2013


Hi Mihai,

> The effort is not the issue here. Do you really think it's work the risk?

I think that if we're not making changes to LLVM because of the risk
then the project has very serious problems, beyond being able to
assemble weird edge cases of ARM instructions.

I've seen projects that get like that, and it's not fun.

> Do you really think this is a better and neater solution?

I do. I think it would be a change worth making even without this work
in the same area motivating it. In fact I'm seriously considering
taking a stab at it myself this weekend.

> If you do, I'll do it - but I must say that the original patch I
> submitted is the solution that makes more
> sense simply because it keeps changes local.

How about doing this incrementally, then? I think a key question your
patch doesn't address is how disassembly will be supported. I've
mentioned it before, but these two lines should not produce the same
output (it'll come up in MC Hammer eventually):

$ echo 0x04,0x00,0x90,0xe2 | bin/llvm-mc -disassemble -arch=arm
    adds r0, r0, #4
$ echo 0x01,0x0f,0x90,0xe2 | bin/llvm-mc -disassemble -arch=arm
    adds r0, r0, #4

I think that the best solution to that problem would involve an
instruction with essentially the form I'm advocating (modulo edge
details like bit-packed imm or two imms and so on). The existing
instructions (ADDri etc) would probably become isCodeGenOnly instead
of the new ones (ADDrii etc) being isAsmParserOnly. So why don't we
plan this in three phases:

1. Commit your patch (or something similar).
2. Add disassembly support to your new instructions, switch
isAsmParserOnly to isCodeGenOnly on the old ones.
3. Go through each use in CodeGen, adapting them to use the new
instruction and remove the legacy ones. We can be sure all uses have
been fixed if we remove the instructions entirely; attempted use will
fail at compile-time.

Even the names actually work out nicely. I don't think ADDrii is
significantly worse than ADDri for those instructions, particularly as
it would remind people who BuildMI them in future that they need to be
careful.

Cheers.

Tim.



More information about the llvm-commits mailing list