On Mon, 12 Dec 2022 at 16:10, Jakub Jelinek wrote:
>
> On Mon, Dec 12, 2022 at 04:56:27PM +0100, Alejandro Colomar wrote:
> > "Names beginning with ‘str’, ‘mem’, or ‘wcs’ followed by a lowercase letter
> > are reserved for additional string and array functions. See String and Array
> > Utilities."
Hi Jakub,
On 12/12/22 17:09, Jakub Jelinek wrote:
On Mon, Dec 12, 2022 at 04:56:27PM +0100, Alejandro Colomar wrote:
"Names beginning with ‘str’, ‘mem’, or ‘wcs’ followed by a lowercase letter
are reserved for additional string and array functions. See String and Array
Utilities."
It is not t
On Mon, Dec 12, 2022 at 04:56:27PM +0100, Alejandro Colomar wrote:
> "Names beginning with ‘str’, ‘mem’, or ‘wcs’ followed by a lowercase letter
> are reserved for additional string and array functions. See String and Array
> Utilities."
It is not that simple.
mem*, str* and wcs* are just potentia
Hi Jonathan and Jakub,
On 12/12/22 15:53, Jakub Jelinek wrote:
On Mon, Dec 12, 2022 at 02:48:35PM +, Jonathan Wakely wrote:
On Mon, 12 Dec 2022 at 14:09, Alejandro Colomar wrote:
On 12/12/22 14:56, Jakub Jelinek wrote:
I think that is the case, plus the question if one can use a non-sta
On Mon, Dec 12, 2022 at 11:35 AM Wilco Dijkstra via Libc-alpha
wrote:
>
> Hi,
>
> I don't believe there is a missing optimization here: compilers expand mempcpy
> by default into memcpy since that is the standard library call. That means
> even
> if your source code contains mempcpy, there will n
On Mon, Dec 12, 2022 at 02:48:35PM +, Jonathan Wakely wrote:
> On Mon, 12 Dec 2022 at 14:09, Alejandro Colomar wrote:
> > On 12/12/22 14:56, Jakub Jelinek wrote:
>
> > > I think that is the case, plus the question if one can use a non-standard
> > > function to implement a standard function (a
On Mon, 12 Dec 2022 at 14:09, Alejandro Colomar wrote:
> On 12/12/22 14:56, Jakub Jelinek wrote:
> > I think that is the case, plus the question if one can use a non-standard
> > function to implement a standard function (and if it would be triggered
> > by seeing an expected prototype for the non
Hi,
I don't believe there is a missing optimization here: compilers expand mempcpy
by default into memcpy since that is the standard library call. That means even
if your source code contains mempcpy, there will never be any calls to mempcpy.
The reason is obvious: most targets support optimized
Hi Jakub,
On 12/12/22 14:56, Jakub Jelinek wrote:
On Mon, Dec 12, 2022 at 02:44:04PM +0100, Alejandro Colomar via Gcc wrote:
I don't see any problem with the code snippets you provided.
Well, then the optimization may be the other way around (although I question
why it is implemented that way
On Mon, Dec 12, 2022 at 02:44:04PM +0100, Alejandro Colomar via Gcc wrote:
> > I don't see any problem with the code snippets you provided.
>
> Well, then the optimization may be the other way around (although I question
> why it is implemented that way, and not the other way around, but I'm not a
--
Subject: Missing optimization: mempcpy(3) vs memcpy(3)
Date: Fri, 9 Dec 2022 18:11:17 +0100
From: Alejandro Colomar
To: gcc@gcc.gnu.org
Hi!
I expect mempcpy(3) to be at least as fast as memcpy(3), since it performs the
same operations, with the exception that mempcpy(3) returns something
On 12/9/22 18:11, Alejandro Colomar via Gcc wrote:
> I expect the compiler to be knowledgeable enough to call whatever is fastest,
> whatever it is, but be consistent in both cases. However, here are the
> results:
Hi.
Note the glibc implementation of mempcpy typically uses (calls) memcpy, thu
Hi!
I expect mempcpy(3) to be at least as fast as memcpy(3), since it performs the
same operations, with the exception that mempcpy(3) returns something useful (as
opposed to memcpy(3), which could perfectly return void), and in fact something
more likely to be in cache, if the copy is perform
13 matches
Mail list logo
