Messages in this thread | | | Date | Wed, 31 Jan 2024 11:13:07 +0200 | Subject | Re: [PATCH 2/3] riscv: optimized memmove | From | Nick Kossifidis <> |
| |
On 1/31/24 07:25, Jisheng Zhang wrote: > > I didn't have c99 spec in hand, but I found gcc explanations about > restrict keyword from [1]: > > "the restrict declaration promises that the code will not access that > object in any other way--only through p." > > So if there's overlap in memcpy, then it contradicts the restrict > implication. > > [1] https://www.gnu.org/software/c-intro-and-ref/manual/html_node/restrict-Pointers.html > The union used in the code also contradicts this. BTW the restrict qualifier isn't used in kernel's lib/string.c nor in the current implementation (https://elixir.bootlin.com/linux/latest/source/arch/riscv/include/asm/string.h#L16).
> And from the manual, if the memcpy users must ensure "The memory areas > must not overlap." So I think all linux kernel's memcpy implementations(only copy > fw and don't take overlap into consideration) are right. > > I did see the alias-memcpy-as-memmove in some libc implementations, but > this is not the style in current kernel's implementations. > > Given current riscv asm implementation also doesn't do the alias and > copy-fw only, and this series improves performance and doesn't introduce the > Is it better to divide this into two steps: Firstly, merge this series > if there's no obvious bug; secondly, do the alias as you suggested, > since you have a basic implementation, you could even submit your patch > ;) What do you think about this two steps solution? >
I still don't understand why you prefer undefined behavior over just aliasing memcpy to memmove. Anyway, do as you wish, I don't have time to work on this unfortunately. Feel free to use the code I shared for bw copy etc.
Regards, Nick
| |