From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Yonghong Song <yhs@meta.com>
Cc: bpf@vger.kernel.org
Subject: Register encoding in assembly for load/store instructions
Date: Tue, 25 Jul 2023 19:29:34 +0200 [thread overview]
Message-ID: <87ila7dhmp.fsf@oracle.com> (raw)
Hello Yonghong.
We have noticed that the llvm disassembler uses different notations for
registers in load and store instructions, depending somehow on the width
of the data being loaded or stored.
For example, this is an excerpt from the assembler-disassembler.s test
file in llvm:
// Note: For the group below w1 is used as a destination for sizes u8, u16, u32.
// This is disassembler quirk, but is technically not wrong, as there are
// no different encodings for 'r1 = load' vs 'w1 = load'.
//
// CHECK: 71 21 2a 00 00 00 00 00 w1 = *(u8 *)(r2 + 0x2a)
// CHECK: 69 21 2a 00 00 00 00 00 w1 = *(u16 *)(r2 + 0x2a)
// CHECK: 61 21 2a 00 00 00 00 00 w1 = *(u32 *)(r2 + 0x2a)
// CHECK: 79 21 2a 00 00 00 00 00 r1 = *(u64 *)(r2 + 0x2a)
r1 = *(u8*)(r2 + 42)
r1 = *(u16*)(r2 + 42)
r1 = *(u32*)(r2 + 42)
r1 = *(u64*)(r2 + 42)
The comment there clarifies that the usage of wN instead of rN in the
u8, u16 and u32 cases is a "disassembler quirk".
Anyway, the problem is that it seems that `clang -S' actually emits
these forms with wN.
Is that intended?
next reply other threads:[~2023-07-25 17:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 17:29 Jose E. Marchesi [this message]
2023-07-25 18:47 ` Register encoding in assembly for load/store instructions Yonghong Song
2023-07-25 18:56 ` Jose E. Marchesi
2023-07-25 19:11 ` Jose E. Marchesi
2023-07-25 19:59 ` Yonghong Song
2023-07-25 19:45 ` Yonghong Song
2023-07-25 20:09 ` Jose E. Marchesi
2023-07-25 22:10 ` Yonghong Song
2023-07-25 22:26 ` Jose E. Marchesi
2023-07-26 0:31 ` Alexei Starovoitov
2023-07-26 0:39 ` Eduard Zingerman
2023-07-26 4:16 ` Yonghong Song
2023-07-26 14:41 ` Eduard Zingerman
2023-07-28 16:58 ` Eduard Zingerman
2023-07-28 21:29 ` Alexei Starovoitov
2023-07-28 23:25 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ila7dhmp.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=bpf@vger.kernel.org \
--cc=yhs@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox