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.
As I mentioned in slack, I realized that PR #42 introduces not correct replacement for
0(Rn)as@Rnwhile 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:
and
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 optimizes0(rn)case), but gnu disassembler always prints0(rn)if it sees the corresponded encoding for both source and destination position.