<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/118038>118038</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
[RISC-V] memcpy vector expansion should use 8B elements
</td>
</tr>
<tr>
<th>Labels</th>
<td>
new issue
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
antonblanchard
</td>
</tr>
</table>
<pre>
clang is using the element size in memcpy vector expansions:
```
#include <string.h>
void foo_64(unsigned long *dst, unsigned long *src)
{
memcpy(dst, src, 16);
}
void foo_8(unsigned char *dst, unsigned char *src)
{
memcpy(dst, src, 16);
}
```
```
foo_64:
vsetivli zero, 2, e64, m1, ta, ma
vle64.v v8, (a1)
vse64.v v8, (a0)
ret
foo_8:
vsetivli zero, 16, e8, m1, ta, ma
vle8.v v8, (a1)
vse8.v v8, (a0)
ret
```
This prevents expansion of the memcpy with 64bit elements on a CPU with vector support but no unaligned vector (eg Spacemit K1). If we always used 8B elements for the copy we wouldn't have this issue. I notice gcc does this.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyklE1vnDwQxz-NuYyCjA0sHDgkm2el6LlUTdtrZcwAroyNsGGbfPrKXtK8tblUsrxez3jmN_-dHeGcGgxiQ4obUtwmYvWjXRphvDWtFkaOYumS1nYPjdTCDKAcrE6ZAfyIgBonNB6cekRQBiac5PwAG0pvF8CfszBOWeMIvyY0rpLui14TxpWReu0QCD86vygzpCPh_11cN6s66K39XuaEVauJnB1oawYg7LpznrAjvLt3iySsDiEONzFQfYEirNqfRI8jZGXw49HpcPsmZ_UyZdDgTymf7v8h5Us5Xn_dK9-FqzeHXm1aEVo_4mJDNBY2DOocYcrC7kU8i_2JxjJPt3Cqwj1hlch20BjwnZX-ti7oL0gXMT6gCDUdAasPKKqPIN4a3zG8lujLqBzMC25ovHvuMLB9bMi9Ac_Kj1DmrfJPLerAGhBw_PT1Ytxb1K3zbBcP7erBWFiN0JffdrcTVuEA97OQOCkP_wf0FO56OCMIfRYP4d-AHVQ3z4l6u0QWaQMJwtmuujOEHTyMYkPwoQTl3Iop3IGxXkmEQUroLLpoTZOu4V3Na5Fgkx04q3hRV1kyNkXLOe3bohQCeZe1lFEqy76nbZdReuCJahhleZaxivGszrO0yKq-PvSZ5EXZ53lPcoqTUDrVeptSuwxJRGmyrKK8SrRoUbs4DRgzeL6AEsbCcFia8OiqXQdHcqqV8-45jFdexzHy-e7-ePWNFLd_GwfgxiBJUO6lcMm66Gb0fo7jgp0IOw3Kj2ubSjsRdgqZ9o-rebE_UHrCTpHPEXbaC9ga9isAAP__LUR3KA">