Does 0(Rn) as [at]Rn printing is not correct?

[chbessonova]

As I mentioned in slack, I realized that PR #42 introduces not correct replacement for 0(Rn) as @Rn while printing a memory operand for an instruction.
The patch makes the replacement for both source and destination position. For source position it looks not correct, since original and printed instructions become not equal by their encoding.
Compare:

mov	@r13, r13               ; encoding: [0x2d,0x4d]

and

mov	0(r13), r13             ; encoding: [0x1d,0x4d,0x00,0x00]

It may be a kind of optimization, but asm printer doesn't look like a good place for this, does it?

For destination position there is no such kind of ambiguity, but there is an opinion that it may confuse a user.

Comparing with gnu toolchain:
I've never seen that gcc prints 0(rn) for both source and destination positions (maybe it optimizes 0(rn) case), but gnu disassembler always prints 0(rn) if it sees the corresponded encoding for both source and destination position.

[asl]

We could implement this as a separate MI-level pass. that would essentially "shrink" the encoding.

[chbessonova]

Ok. Then I'll try to do so.

[mskvortsov]

Isn't that the SelectionDAG job to select an optimal instruction form / addressing mode?

[asl]

Yes and no :)

1. We can do isel not via SDAG (e.g. FastISel / GlobalISel)
2. There are bunch of MI-level stuff that could change the instruction form

[chbessonova]

@asl
I made a kind of a draft pass here chbessonova@c9fde61 which replaces MOV16rm with 0 offset to MOV16rn.
I'm completely new in backend, so could you, please, take a look? Does it look like a correct way to do the things?
If not, please, give me another hint :)