linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	christoph.muellner@vrull.eu, conor@kernel.org,
	philipp.tomsich@vrull.eu, jszhang@kernel.org
Subject: Re: [PATCH v4 4/5] RISC-V: add infrastructure to allow different str* implementations
Date: Tue, 10 Jan 2023 11:46:40 +0100	[thread overview]
Message-ID: <1994655.QkHrqEjB74@diego> (raw)
In-Reply-To: <20230110093936.nzc3nkrkqkkzxkaq@orel>

Hi Andrew,

Am Dienstag, 10. Januar 2023, 10:39:36 CET schrieb Andrew Jones:
> On Mon, Jan 09, 2023 at 07:17:54PM +0100, Heiko Stuebner wrote:
> > From: Heiko Stuebner <heiko.stuebner@vrull.eu>
> > 
> > Depending on supported extensions on specific RISC-V cores,
> > optimized str* functions might make sense.
> > 
> > This adds basic infrastructure to allow patching the function calls
> > via alternatives later on.
> > 
> > The Linux kernel provides standard implementations for string functions
> > but when architectures want to extend them, they need to provide their
> > own.
> 
> And the compiler provides builtins. In the previous series it appeared
> to be a bad idea to compile the kernel with the compiler's builtins
> disabled. How will the optimized string functions which will be based
> on this patch be selected?

yep, the consensus seemingly was that the compiler knows best when
to use builtins for some cases (which is probably correct), hence the move
away from the inline bases.

So I guess the first decision is the compiler's wether to use a builtin or
the kernel string function (same as for mem*) .

In my tests, I did see both getting used - so it's definitly not lost work :-) .

After that when landing in these here, we want to select the best variant
for the host-system the kernel runs on.

I.e. this one as baseline or for example using zbb as an "alternative".

As for the "more" variants, I currently have more patches on top, that
then use an ALTERNATIVE_2

ALTERNATIVE_2("nop",
      "j variant_zbb_unaligned", 0, CPUFEATURE_ZBB | CPUFEATURE_FAST_UNALIGNED, 0, CONFIG_RISCV_ISA_ZBB,
      "j variant_zbb", 0, CPUFEATURE_ZBB, CPUFEATURE_FAST_UNALIGNED, CONFIG_RISCV_ISA_ZBB)

with the "errata_id" being used as a bitfield to use extension combinations.
And a "not"-field, so I can do a has-zbb + has-not-fast-unaligned


Heiko



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

  reply	other threads:[~2023-01-10 10:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 18:17 [PATCH v4 0/5] Zbb string optimizations and call support in alternatives Heiko Stuebner
2023-01-09 18:17 ` [PATCH v4 1/5] RISC-V: move some stray __RISCV_INSN_FUNCS definitions from kprobes Heiko Stuebner
2023-01-09 20:53   ` Conor Dooley
2023-01-11 15:14     ` Heiko Stübner
2023-01-10  8:32   ` Andrew Jones
2023-01-09 18:17 ` [PATCH v4 2/5] RISC-V: add helpers for J-type immediate handling Heiko Stuebner
2023-01-09 22:22   ` Conor Dooley
2023-01-10  8:44   ` Andrew Jones
2023-01-10  8:54     ` Conor Dooley
2023-01-11 14:43       ` Jisheng Zhang
2023-01-09 18:17 ` [PATCH v4 3/5] RISC-V: fix jal addresses in patched alternatives Heiko Stuebner
2023-01-10  9:28   ` Andrew Jones
2023-01-11 17:15     ` Jisheng Zhang
2023-01-11 13:18   ` Jisheng Zhang
2023-01-11 13:53     ` Heiko Stübner
2023-01-11 14:15     ` Andrew Jones
2023-01-11 14:44       ` Jisheng Zhang
2023-01-09 18:17 ` [PATCH v4 4/5] RISC-V: add infrastructure to allow different str* implementations Heiko Stuebner
2023-01-09 22:37   ` Conor Dooley
2023-01-09 23:31     ` Heiko Stübner
2023-01-10  9:39   ` Andrew Jones
2023-01-10 10:46     ` Heiko Stübner [this message]
2023-01-10 11:16       ` Andrew Jones
2023-01-11 12:34         ` Andrew Jones
     [not found]           ` <CAEg0e7gJgpoiGjfLeedba0-r=dCE1Z_qkU53w_+-cVjsuqaC3A@mail.gmail.com>
2023-01-11 13:42             ` Philipp Tomsich
2023-01-11 13:47             ` Andrew Jones
2023-01-10 12:13   ` Andrew Jones
2023-01-11 12:30     ` Andrew Jones
2023-01-12 16:05     ` Heiko Stübner
2023-01-09 18:17 ` [PATCH v4 5/5] RISC-V: add zbb support to string functions Heiko Stuebner
2023-01-09 20:39   ` Conor Dooley
2023-01-10  9:57   ` Andrew Jones
2023-01-10 10:14     ` Conor Dooley
2023-01-12 11:21       ` Heiko Stübner
2023-01-12 12:06         ` Conor Dooley
2023-01-12 12:28           ` Heiko Stübner
2023-01-11 12:24   ` Andrew Jones
2023-01-11 14:27     ` Christoph Müllner
2023-01-11 15:16       ` Andrew Jones
2023-01-11 15:22       ` Jeff Law
2023-01-12 22:05     ` Heiko Stübner
2023-01-11 13:24 ` [PATCH v4 0/5] Zbb string optimizations and call support in alternatives Jisheng Zhang

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=1994655.QkHrqEjB74@diego \
    --to=heiko@sntech.de \
    --cc=ajones@ventanamicro.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=conor@kernel.org \
    --cc=jszhang@kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=philipp.tomsich@vrull.eu \
    /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;
as well as URLs for NNTP newsgroup(s).