summaryrefslogtreecommitdiffstats
path: root/src/vppinfra/memcpy_sse3.h
AgeCommit message (Collapse)AuthorFilesLines
2018-10-23c11 safe string handling supportDave Barach1-1/+1
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2017-12-14vppinfra: add AVX512 variant of clib_memcpyDamjan Marion1-29/+33
Taken from DPDK, also AVX2 variant updated to be in sync with DPDK version. Change-Id: I8a42e4141a5a1a8cfbee328b07bd0c9b38a9eb05 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-07-06vppinfra: revert clib_memcpy optimizationDamjan Marion1-5/+6
Looks like some compiler versions are producing wrong code when we are copying 9-16 bytes so reverting back to the original code. Change-Id: I74b5fa54a3b01f6288648f1cb0926030edd3b26f Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-04-21vppinfra: clib_memcpy improvementRay Kinsella1-5/+0
In the case where n is a constant 16 bytes, the second load/store is ignored by the load/store unit - it has neglible/zero cost. In the case where n is variable and greater than 512 bytes, the extra if (n == 16) branch has a very small performance impact. Change-Id: I04b313cf022c18fee31b1d9bcf6a128414659a99 Signed-off-by: Ray Kinsella <ray.kinsella@intel.com>
2017-03-01vppinfra: fix issue when copying 16 bytes with clib_memcpyDamjan Marion1-0/+5
Current code wos copying same data twice when length is 16. Change-Id: I8d935b32f61672aaea9789c097a5083ae8f78cdd Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+355
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>