This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Expand mempcpy into memcpy
From: Ondřej Bílka <neleai@seznam.cz>
Date: Wed, 6 Feb 2013 20:25:24 +0100
> On Wed, Feb 06, 2013 at 01:40:00PM -0500, David Miller wrote:
>> From: Ondřej Bílka <neleai@seznam.cz>
>> Date: Wed, 6 Feb 2013 18:40:21 +0100
>>
>> > This makes all mempcpy call to call memcpy instead.
>> >
>> > There are two reasons, one is that it will simplify maintainance.
>> > Second is that posible performance gains are saving one addition and
>> > perhaps spilling one register. Problem is that implementation is quite
>> > big - 1105 bytes on x64. Probably cost of instruction/branch cache
>> > misses outweigth speedup we gained.
>> >
>> > I will move unused inline functions later.
>>
>> The overhead of mempcpy vs. memcpy on sparc is exactly 2 instructions
>> and 1 extra cycle.
>>
>> I think you are making an extremely cpu specific decision on how this
>> macro behaves.
>
> I wrote this unclearly.
> "that posible performance gains are saving one addition and perhaps spilling one register."
> comment refered to old macro.
>
> Then downside of old macro is that memcpy and mempcpy occupy 2000 bytes
> of instruction cache.
>
> With my change with memcpy only 1000 bytes will be occupied which means
> fewer cache misses.
On sparc there is no such extra icache space.
mempcpy is simply a 2-instruction stub which sets up a return value
register and branches into memcpy.
If x86 implements this by having yet another entire copy of the memcpy
core for the sake of mempcpy, that's frankly an implementation mis-feature.