Support parsing LDD/STD instructions

[dylanmckay]

The parser does not handle the Y+2, Z+3 operand types.

Once this instruction is fixed, take the XFAIL attribute from test/MC/AVR/inst-ldd.s and test/MC/AVR/inst-std.s.

[dylanmckay]

One possible solution would be to create a custom operand type with a custom parser match class. It is unclear how clean this solution will be. I tried this in a private branch. I could successfully parse the <PTR>+<IMM> operands into a custom operand named memri (memory register+immediate). The problem was that how would the instruction bit fields map to the operand.

We would normally have a bitfield for each of the register and the immediate. If these two are concatenated into one operand, we probably have to write a custom encoder method to concatenate the bits and extract them in AVRInstrInfo.td. This may not be such a bad idea, however. We currently have a hack that defines an extra bit for the pointer register variable for LD/ST (because the bit depends on the instruction itself, this provided a hook so we can check the instruction in C++ and set the bit appropriately). We could hoist this up to memri and then turn LD r5, Y into an alias of LDD r5, Y+0.

That depends on whether we will be able to express an operand of type memri in an InstAlias, and it is also complicated because LD and ST are defined for the X, Y, and Z pointer registers, but LDD and STD are only defined for Y and Z. It is also less useful because the postincrement/predecrement variants of LD and ST are not aliases of LDD and STD in terms of machine code representation.

[agnat]

The parsing bit is fixed in 204b291. The encoding part was done in 9de9e69.

Looks done to me.

[dylanmckay]

I concur.