Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Subject: Re: [PATCH] riscv: Fix build with CONFIG_CC_OPTIMIZE_FOR_SIZE=y
From:   Jessica Clarke <jrtc27@jrtc27.com>
In-Reply-To: <2546376.ElGaqSPkdT@phil>
Date:   Thu, 22 Sep 2022 16:52:46 +0100
Cc:     Palmer Dabbelt <palmer@dabbelt.com>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        Samuel Holland <samuel@sholland.org>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Anup Patel <anup@brainfault.org>,
        Atish Patra <atishp@rivosinc.com>, Dao Lu <daolu@rivosinc.com>,
        Guo Ren <guoren@kernel.org>,
        Jisheng Zhang <jszhang@kernel.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E96A836-764D-4D07-AB79-3861B9CC2B1F@jrtc27.com>
References: <20220922060958.44203-1-samuel@sholland.org>
 <2546376.ElGaqSPkdT@phil>
To:     Heiko Stuebner <heiko@sntech.de>
Precedence: bulk

On 22 Sept 2022, at 16:45, Heiko Stuebner <heiko@sntech.de> wrote:
>=20
> Am Donnerstag, 22. September 2022, 08:09:58 CEST schrieb Samuel =
Holland:
>> commit 8eb060e10185 ("arch/riscv: add Zihintpause support") broke
>> building with CONFIG_CC_OPTIMIZE_FOR_SIZE enabled (gcc 11.1.0):
>>=20
>> CC arch/riscv/kernel/vdso/vgettimeofday.o
>> In file included from <command-line>:
>> ./arch/riscv/include/asm/jump_label.h: In function 'cpu_relax':
>> ././include/linux/compiler_types.h:285:33: warning: 'asm' operand 0 =
probably does not match constraints
>> 285 | #define asm_volatile_goto(x...) asm goto(x)
>> | ^~~
>> ./arch/riscv/include/asm/jump_label.h:41:9: note: in expansion of =
macro 'asm_volatile_goto'
>> 41 | asm_volatile_goto(
>> | ^~~~~~~~~~~~~~~~~
>> ././include/linux/compiler_types.h:285:33: error: impossible =
constraint in 'asm'
>> 285 | #define asm_volatile_goto(x...) asm goto(x)
>> | ^~~
>> ./arch/riscv/include/asm/jump_label.h:41:9: note: in expansion of =
macro 'asm_volatile_goto'
>> 41 | asm_volatile_goto(
>> | ^~~~~~~~~~~~~~~~~
>> make[1]: *** [scripts/Makefile.build:249: =
arch/riscv/kernel/vdso/vgettimeofday.o] Error 1
>> make: *** [arch/riscv/Makefile:128: vdso_prepare] Error 2
>>=20
>> Having a static branch in cpu_relax() is problematic because that
>> function is widely inlined, including in some quite complex functions
>> like in the VDSO. A quick measurement shows this static branch is
>> responsible by itself for around 40% of the jump table.
>>=20
>> Drop the static branch, which ends up being the same number of
>> instructions anyway. If Zihintpause is supported, we trade the nop =
from
>> the static branch for a div. If Zihintpause is unsupported, we trade =
the
>> jump from the static branch for (what gets interpreted as) a nop.
>>=20
>> Fixes: 8eb060e10185 ("arch/riscv: add Zihintpause support")
>> Signed-off-by: Samuel Holland <samuel@sholland.org>
>> ---
>>=20
>> arch/riscv/include/asm/hwcap.h | 3 ---
>> arch/riscv/include/asm/vdso/processor.h | 25 =
++++++++++---------------
>> 2 files changed, 10 insertions(+), 18 deletions(-)
>>=20
>> diff --git a/arch/riscv/include/asm/hwcap.h =
b/arch/riscv/include/asm/hwcap.h
>> index 6f59ec64175e..b21d46e68386 100644
>> --- a/arch/riscv/include/asm/hwcap.h
>> +++ b/arch/riscv/include/asm/hwcap.h
>> @@ -68,7 +68,6 @@ enum riscv_isa_ext_id {
>> */
>> enum riscv_isa_ext_key {
>> 	RISCV_ISA_EXT_KEY_FPU,		/* For 'F' and 'D' */
>> -	RISCV_ISA_EXT_KEY_ZIHINTPAUSE,
>> 	RISCV_ISA_EXT_KEY_MAX,
>> };
>>=20
>> @@ -88,8 +87,6 @@ static __always_inline int riscv_isa_ext2key(int =
num)
>> 		return RISCV_ISA_EXT_KEY_FPU;
>> 	case RISCV_ISA_EXT_d:
>> 		return RISCV_ISA_EXT_KEY_FPU;
>> -	case RISCV_ISA_EXT_ZIHINTPAUSE:
>> -		return RISCV_ISA_EXT_KEY_ZIHINTPAUSE;
>> 	default:
>> 		return -EINVAL;
>> 	}
>> diff --git a/arch/riscv/include/asm/vdso/processor.h =
b/arch/riscv/include/asm/vdso/processor.h
>> index 1e4f8b4aef79..789bdb8211a2 100644
>> --- a/arch/riscv/include/asm/vdso/processor.h
>> +++ b/arch/riscv/include/asm/vdso/processor.h
>> @@ -4,30 +4,25 @@
>>=20
>> #ifndef __ASSEMBLY__
>>=20
>> -#include <linux/jump_label.h>
>> #include <asm/barrier.h>
>> -#include <asm/hwcap.h>
>>=20
>> static inline void cpu_relax(void)
>> {
>> -	if =
(!static_branch_likely(&riscv_isa_ext_keys[RISCV_ISA_EXT_KEY_ZIHINTPAUSE])=
) {
>> #ifdef __riscv_muldiv
>> -		int dummy;
>> -		/* In lieu of a halt instruction, induce a long-latency =
stall. */
>> -		__asm__ __volatile__ ("div %0, %0, zero" : "=3Dr" =
(dummy));
>> +	int dummy;
>> +	/* In lieu of a halt instruction, induce a long-latency stall. =
*/
>> +	__asm__ __volatile__ ("div %0, %0, zero" : "=3Dr" (dummy));
>> #endif
>> -	} else {
>> -		/*
>> -		 * Reduce instruction retirement.
>> -		 * This assumes the PC changes.
>> -		 */
>> +	/*
>> +	 * Reduce instruction retirement.
>> +	 * This assumes the PC changes.
>> +	 */
>> #ifdef __riscv_zihintpause
>> -		__asm__ __volatile__ ("pause");
>> +	__asm__ __volatile__ ("pause");
>> #else
>> -		/* Encoding of the pause instruction */
>> -		__asm__ __volatile__ (".4byte 0x100000F");
>> +	/* Encoding of the pause instruction */
>> +	__asm__ __volatile__ (".4byte 0x100000F");
>> #endif
>=20
> hmm, though before this part of the code was only ever accessed
> when the zhintpause extension was really available on the running
> machine while now the pause instruction is called every time.
>=20
> So I'm just wondering, can't this run into some "illegal instruction"
> thingy on machines not supporting the extension?

No. The encoding for pause was deliberately chosen to be one of the
=E2=80=9Cuseless=E2=80=9D encodings of fence, with the hope that =
existing
microarchitectures might take a while to execute it and thus it would
still function as a slow-running instruction. It=E2=80=99s somewhat
questionable whether the div is even needed, the worst that happens is
cpu_relax isn=E2=80=99t very relaxed and you spin a bit faster. Any
implementations where that=E2=80=99s true probably also don=E2=80=99t =
have fancy
clock/power management anyway, and div isn=E2=80=99t going to be a =
low-power
operation so the only real effect is likely hammering on contended
atomics a bit more, and who cares about that on the low core count
systems we have today.

Jess