Re: [PATCH] Expand mempcpy into memcpy

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Feb 6, 2013 at 11:43 AM, David Miller <davem@davemloft.net> wrote:
> 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.

Yes, we should remove mempcpy body from x86-64.  Liubov, can you
take a look?

Thanks.

-- 
H.J.