All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <ajones@ventanamicro.com>
To: "Heiko Stübner" <heiko@sntech.de>
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: Wed, 11 Jan 2023 13:34:36 +0100	[thread overview]
Message-ID: <20230111123436.6qq3syh24prrs7o7@orel> (raw)
In-Reply-To: <20230110111647.vg4fdclz4hzcuaj3@orel>

On Tue, Jan 10, 2023 at 12:16:47PM +0100, Andrew Jones wrote:
> On Tue, Jan 10, 2023 at 11:46:40AM +0100, Heiko Stübner wrote:
> > 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*) .

Hi Heiko,

Thinking about this some more, I'd still like to understand how/when the
compiler makes this choice. Are compiler flags involved? Or do some
heuristics dictate the choice?

Thanks,
drew

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

  reply	other threads:[~2023-01-11 12:34 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
2023-01-10 11:16       ` Andrew Jones
2023-01-11 12:34         ` Andrew Jones [this message]
     [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=20230111123436.6qq3syh24prrs7o7@orel \
    --to=ajones@ventanamicro.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=conor@kernel.org \
    --cc=heiko@sntech.de \
    --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 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.