From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1D711F927
	for <bpf@vger.kernel.org>; Tue, 25 Jul 2023 18:47:41 +0000 (UTC)
Received: from out-25.mta0.migadu.com (out-25.mta0.migadu.com [91.218.175.25])
	by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F02C419B4
	for <bpf@vger.kernel.org>; Tue, 25 Jul 2023 11:47:39 -0700 (PDT)
Message-ID: <5e6b7c30-eba4-31ca-e0ac-1e21f4c9d8aa@linux.dev>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1690310858; h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=xoxyn36nrDR+Yit6z7A+tz+QJu1vbLc9nYsxPs6ASXg=;
	b=RA5QUb/7VUyky+Su/zZl6TbKCqLp8/LajxLZj5uFhQLGLy2JNXVtVRfkxfbulGlRkg+reX
	mF+OaViMYbyc9BY54pe4k1own4GV1IW62jk/jShHc657mCsUXU+Hu70UlDCnpBKEtXfQeR
	ecrPffGt7iPVdNoCcAObUstghH/ddaU=
Date: Tue, 25 Jul 2023 11:47:35 -0700
Precedence: bulk
X-Mailing-List: bpf@vger.kernel.org
List-Id: <bpf.vger.kernel.org>
List-Subscribe: <mailto:bpf+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:bpf+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Reply-To: yonghong.song@linux.dev
Subject: Re: Register encoding in assembly for load/store instructions
Content-Language: en-US
To: "Jose E. Marchesi" <jose.marchesi@oracle.com>,
 Yonghong Song <yhs@meta.com>
Cc: bpf@vger.kernel.org
References: <87ila7dhmp.fsf@oracle.com>
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Yonghong Song <yonghong.song@linux.dev>
In-Reply-To: <87ila7dhmp.fsf@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Migadu-Flow: FLOW_OUT
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net



On 7/25/23 10:29 AM, Jose E. Marchesi wrote:
> 
> 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?

Yes, this is intended since alu32 mode is enabled where
w* registers are used for 8/16/32 bit load.

Note that for newer sign-extended loads, even at alu32 mode,
only r* register is used since the sign-extension extends
upto 64 bits for all variants (8/16/32).



>