All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Vivian Wang <wangruikang@iscas.ac.cn>
Cc: "Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Charlie Jenkins" <charlie@rivosinc.com>,
	"Xiao Wang" <xiao.w.wang@intel.com>,
	"Christoph Müllner" <christoph.muellner@vrull.eu>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Vivian Wang" <uwu@dram.page>
Subject: Re: [PATCH v2 4/5] riscv: bitops: Use __riscv_has_extension_likely
Date: Tue, 26 Aug 2025 23:48:57 -0400	[thread overview]
Message-ID: <aK6AKTnUtthEnEyy@yury> (raw)
In-Reply-To: <4dba27c4-e7a5-4ffc-8073-08a83c68e527@iscas.ac.cn>

On Fri, Aug 22, 2025 at 01:46:19AM +0800, Vivian Wang wrote:
> On 8/21/25 22:44, Yury Norov wrote:
> 
> > On Thu, Aug 21, 2025 at 05:16:34PM +0800, Vivian Wang wrote:
> >> Use __riscv_has_extension_likely() to check for RISCV_ISA_EXT_ZBB,
> >> replacing the use of asm goto with ALTERNATIVE.
> >>
> >> The "likely" variant is used to match the behavior of the original
> >> implementation using ALTERNATIVE("j %l[legacy]", "nop", ...).
> >>
> >> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> >> ---
> >>  arch/riscv/include/asm/bitops.h | 32 ++++++++------------------------
> >>  1 file changed, 8 insertions(+), 24 deletions(-)
> >>
> >> diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
> >> index d59310f74c2ba70caeb7b9b0e9221882117583f5..f70ccc0c2ffb86a6fda3bc373504143d0c6a1093 100644
> >> --- a/arch/riscv/include/asm/bitops.h
> >> +++ b/arch/riscv/include/asm/bitops.h
> >> @@ -47,9 +47,8 @@
> >>  
> >>  static __always_inline unsigned long variable__ffs(unsigned long word)
> >>  {
> >> -	asm goto(ALTERNATIVE("j %l[legacy]", "nop", 0,
> >> -				      RISCV_ISA_EXT_ZBB, 1)
> >> -			  : : : : legacy);
> >> +	if (!__riscv_has_extension_likely(0, RISCV_ISA_EXT_ZBB))
> >> +		return generic___ffs(word);
> > So, on the previous round you spent quite a lot of time explaining how
> > 'unlikely()' version is handy over '!likely()', and now use just the
> > latter. I feel really lost about how the code generation should look.
> 
> It's not "handy". The operative part is "has_extension", and both
> functions return true if the extension is available and false if not.
> Functionally:
> 
>     if (likely()) <-- equivalent --> if (unlikely())
>     if (!likely()) <-- equivalent --> if (!unlikely())
> 
> Whereas:
> 
>     if (likely()) <-- **opposite of** --> if (!unlikely())
>     if (unlikely()) <-- **opposite of** --> if (!likely())
> 
> All the asm goto dispatch stuff work like this:
> static_branch_{likely,unlikely}, (arm64)
> alternative_has_cap_{likely,unlikely},
> __riscv_has_extension_{likely,unlikely}. Maybe it's confusing, but it
> seems to be the convention.
> 
> And, codegen-wise:
> 
> ALTERNATIVE("j %l[no_alt]", "nop", ...) -> likely() ALTERNATIVE("nop",
> "j %l[has_alt]", ...) -> unlikely()
> 
> Since the original code has the "likely" pattern, using "if (likely())"
> preserves it. Whatever the codegen was, it's still the same.
> 
> > Can you please share bloat-o-meter report against this patch? Can you
> > also show an example of code generation before and after? Have you
> > tried the 'unlikely()` one? How the output looks?
> 
> Thanks for the tip on bloat-o-meter. I'll take a look tomorrow.
> 
> >>  	asm volatile (".option push\n"
> >>  		      ".option arch,+zbb\n"
> > Yeah, now the diff is much cleaner. Thanks.
> 
> This is why the condition at the top needed to be "!has_extension". So
> the structure can be:
> 
>     if (!has_extension)
>         return sw_version;
> 
>     multi_line
>     zbb_version;
> 
> If I used "if (has_extension)" the code would need be
> 
>     if (has_extension) {
>         multi_line
>         zbb_version;
>     } else {
>         sw_version;
>     }
> 
> And whether it was "likely" or "unlikely" had no bearing on the
> structure of the code.

OK, I see. Sorry for confusion.

Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Vivian Wang <wangruikang@iscas.ac.cn>
Cc: "Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Alexandre Ghiti" <alex@ghiti.fr>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Charlie Jenkins" <charlie@rivosinc.com>,
	"Xiao Wang" <xiao.w.wang@intel.com>,
	"Christoph Müllner" <christoph.muellner@vrull.eu>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Vivian Wang" <uwu@dram.page>
Subject: Re: [PATCH v2 4/5] riscv: bitops: Use __riscv_has_extension_likely
Date: Tue, 26 Aug 2025 23:48:57 -0400	[thread overview]
Message-ID: <aK6AKTnUtthEnEyy@yury> (raw)
In-Reply-To: <4dba27c4-e7a5-4ffc-8073-08a83c68e527@iscas.ac.cn>

On Fri, Aug 22, 2025 at 01:46:19AM +0800, Vivian Wang wrote:
> On 8/21/25 22:44, Yury Norov wrote:
> 
> > On Thu, Aug 21, 2025 at 05:16:34PM +0800, Vivian Wang wrote:
> >> Use __riscv_has_extension_likely() to check for RISCV_ISA_EXT_ZBB,
> >> replacing the use of asm goto with ALTERNATIVE.
> >>
> >> The "likely" variant is used to match the behavior of the original
> >> implementation using ALTERNATIVE("j %l[legacy]", "nop", ...).
> >>
> >> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> >> ---
> >>  arch/riscv/include/asm/bitops.h | 32 ++++++++------------------------
> >>  1 file changed, 8 insertions(+), 24 deletions(-)
> >>
> >> diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
> >> index d59310f74c2ba70caeb7b9b0e9221882117583f5..f70ccc0c2ffb86a6fda3bc373504143d0c6a1093 100644
> >> --- a/arch/riscv/include/asm/bitops.h
> >> +++ b/arch/riscv/include/asm/bitops.h
> >> @@ -47,9 +47,8 @@
> >>  
> >>  static __always_inline unsigned long variable__ffs(unsigned long word)
> >>  {
> >> -	asm goto(ALTERNATIVE("j %l[legacy]", "nop", 0,
> >> -				      RISCV_ISA_EXT_ZBB, 1)
> >> -			  : : : : legacy);
> >> +	if (!__riscv_has_extension_likely(0, RISCV_ISA_EXT_ZBB))
> >> +		return generic___ffs(word);
> > So, on the previous round you spent quite a lot of time explaining how
> > 'unlikely()' version is handy over '!likely()', and now use just the
> > latter. I feel really lost about how the code generation should look.
> 
> It's not "handy". The operative part is "has_extension", and both
> functions return true if the extension is available and false if not.
> Functionally:
> 
>     if (likely()) <-- equivalent --> if (unlikely())
>     if (!likely()) <-- equivalent --> if (!unlikely())
> 
> Whereas:
> 
>     if (likely()) <-- **opposite of** --> if (!unlikely())
>     if (unlikely()) <-- **opposite of** --> if (!likely())
> 
> All the asm goto dispatch stuff work like this:
> static_branch_{likely,unlikely}, (arm64)
> alternative_has_cap_{likely,unlikely},
> __riscv_has_extension_{likely,unlikely}. Maybe it's confusing, but it
> seems to be the convention.
> 
> And, codegen-wise:
> 
> ALTERNATIVE("j %l[no_alt]", "nop", ...) -> likely() ALTERNATIVE("nop",
> "j %l[has_alt]", ...) -> unlikely()
> 
> Since the original code has the "likely" pattern, using "if (likely())"
> preserves it. Whatever the codegen was, it's still the same.
> 
> > Can you please share bloat-o-meter report against this patch? Can you
> > also show an example of code generation before and after? Have you
> > tried the 'unlikely()` one? How the output looks?
> 
> Thanks for the tip on bloat-o-meter. I'll take a look tomorrow.
> 
> >>  	asm volatile (".option push\n"
> >>  		      ".option arch,+zbb\n"
> > Yeah, now the diff is much cleaner. Thanks.
> 
> This is why the condition at the top needed to be "!has_extension". So
> the structure can be:
> 
>     if (!has_extension)
>         return sw_version;
> 
>     multi_line
>     zbb_version;
> 
> If I used "if (has_extension)" the code would need be
> 
>     if (has_extension) {
>         multi_line
>         zbb_version;
>     } else {
>         sw_version;
>     }
> 
> And whether it was "likely" or "unlikely" had no bearing on the
> structure of the code.

OK, I see. Sorry for confusion.

Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>

  parent reply	other threads:[~2025-08-27  3:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21  9:16 [PATCH v2 0/5] riscv: Use __riscv_has_extension_{likely,unlikely} Vivian Wang
2025-08-21  9:16 ` Vivian Wang
2025-08-21  9:16 ` [PATCH v2 1/5] riscv: pgtable: Use __riscv_has_extension_unlikely Vivian Wang
2025-08-21  9:16   ` Vivian Wang
2025-08-21  9:16 ` [PATCH v2 2/5] riscv: checksum: Use __riscv_has_extension_likely Vivian Wang
2025-08-21  9:16   ` Vivian Wang
2025-08-21  9:16 ` [PATCH v2 3/5] riscv: hweight: " Vivian Wang
2025-08-21  9:16   ` Vivian Wang
2025-08-21  9:16 ` [PATCH v2 4/5] riscv: bitops: " Vivian Wang
2025-08-21  9:16   ` Vivian Wang
2025-08-21 14:44   ` Yury Norov
2025-08-21 14:44     ` Yury Norov
2025-08-21 17:46     ` Vivian Wang
2025-08-21 17:46       ` Vivian Wang
2025-08-21 17:49       ` Vivian Wang
2025-08-21 17:49         ` Vivian Wang
2025-08-27  3:48       ` Yury Norov [this message]
2025-08-27  3:48         ` Yury Norov
2025-08-27  7:07       ` Vivian Wang
2025-08-27  7:07         ` Vivian Wang
2025-08-21  9:16 ` [PATCH v2 5/5] riscv: cmpxchg: " Vivian Wang
2025-08-21  9:16   ` Vivian Wang

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=aK6AKTnUtthEnEyy@yury \
    --to=yury.norov@gmail.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=charlie@rivosinc.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=uwu@dram.page \
    --cc=wangruikang@iscas.ac.cn \
    --cc=xiao.w.wang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.