From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C1A60C47258 for ; Wed, 31 Jan 2024 05:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=anfvFTOl/Wp6fm5STJQvhFbu6IQ5l9KFHKm0GcvpfVQ=; b=2dwu5Wu+0OdqwS ZAw1lDyQgx0sDK6fR0zziTijATMeKHVOmMOp//jYKR9TLPID12K2j7id9vGfrwbMLidXjjuBmz0ML VOxyyV10vWDCQSuKZ/8InZpihbgJnKmUME94C/SVvzFSsQZHwQ5w+BvompmkrQC1g44eVaF7O2VyT yk5UOyYcD4ISz5n468umtYvMjai04prT5QHNQNbVEPQ9OR3nTBmMHtdHxYsHugz0JdiPGPUOhyz4N PV0Dl/70PzZuOk9N+yz/5EXRp8IsnFK7FybYGYPw5w6lY9/u2Um0tgQKNLyNLC7CW9qz2oSM8IbLa Dy57NByZegMuxF/llzDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rV3Ij-00000001YGT-0xPM; Wed, 31 Jan 2024 05:38:21 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rV3Ig-00000001YFz-0rtj for linux-riscv@lists.infradead.org; Wed, 31 Jan 2024 05:38:19 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 330A5CE1DAB; Wed, 31 Jan 2024 05:38:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB433C43390; Wed, 31 Jan 2024 05:38:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706679493; bh=22Krx4btf00/8e1ZZBBu8MzhsLLX45dV/yNclvUWUag=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SprPIEdeeiOm1uug0/HcOCQDu8xShAIOqfy+Lr8SVYVikVDl3aI9ONVCm1PDroLb1 /BBHiEG3trPAcQac98allr6kqurTPWi3T/1CU/PDwPa5WreOBblJ06FFQG63/iXQK8 c1pDO19/jRPVQ2ZTmkW4gLUv20otv3aiF+NVanjiOKc1j95D4q0k0APJIt0a7JLLw/ VvaqDj03CMt0Z19iCHhUPPiRIZp5JLNPh4DEVmUjvSJtsDDzHIOE/gen0ZBU8Z+FCC iLPTFwl638xcT/bFSayT0AriKuzt6aMpfFNTa6R6FJXhcleU9ee3OTpMF8Of7QEF19 rsNbZ5uKJN0Zg== Date: Wed, 31 Jan 2024 13:25:10 +0800 From: Jisheng Zhang To: Nick Kossifidis Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Matteo Croce , kernel test robot Subject: Re: [PATCH 2/3] riscv: optimized memmove Message-ID: References: <20240128111013.2450-1-jszhang@kernel.org> <20240128111013.2450-3-jszhang@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240130_213818_624980_66594C32 X-CRM114-Status: GOOD ( 30.77 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gVHVlLCBKYW4gMzAsIDIwMjQgYXQgMDY6NTI6MjRQTSArMDIwMCwgTmljayBLb3NzaWZpZGlz IHdyb3RlOgo+IE9uIDEvMzAvMjQgMTU6MTIsIEppc2hlbmcgWmhhbmcgd3JvdGU6Cj4gPiBPbiBU dWUsIEphbiAzMCwgMjAyNCBhdCAwMTozOToxMFBNICswMjAwLCBOaWNrIEtvc3NpZmlkaXMgd3Jv dGU6Cj4gPiA+IE9uIDEvMjgvMjQgMTM6MTAsIEppc2hlbmcgWmhhbmcgd3JvdGU6Cj4gPiA+ID4g RnJvbTogTWF0dGVvIENyb2NlIDxtY3JvY2VAbWljcm9zb2Z0LmNvbT4KPiA+ID4gPiAKPiA+ID4g PiBXaGVuIHRoZSBkZXN0aW5hdGlvbiBidWZmZXIgaXMgYmVmb3JlIHRoZSBzb3VyY2Ugb25lLCBv ciB3aGVuIHRoZQo+ID4gPiA+IGJ1ZmZlcnMgZG9lc24ndCBvdmVybGFwLCBpdCdzIHNhZmUgdG8g dXNlIG1lbWNweSgpIGluc3RlYWQsIHdoaWNoIGlzCj4gPiA+ID4gb3B0aW1pemVkIHRvIHVzZSBh IGJpZ2dlciBkYXRhIHNpemUgcG9zc2libGUuCj4gPiA+ID4gCj4gPiA+ID4gU2lnbmVkLW9mZi1i eTogTWF0dGVvIENyb2NlIDxtY3JvY2VAbWljcm9zb2Z0LmNvbT4KPiA+ID4gPiBSZXBvcnRlZC1i eToga2VybmVsIHRlc3Qgcm9ib3QgPGxrcEBpbnRlbC5jb20+Cj4gPiA+ID4gU2lnbmVkLW9mZi1i eTogSmlzaGVuZyBaaGFuZyA8anN6aGFuZ0BrZXJuZWwub3JnPgo+ID4gPiAKPiA+ID4gSSdkIGV4 cGVjdCB0byBoYXZlIG1lbW1vdmUgaGFuZGxlIGJvdGggZncvYncgY29weWluZyBhbmQgdGhlbiBt ZW1jcHkgYmVpbmcKPiA+ID4gYW4gYWxpYXMgdG8gbWVtbW92ZSwgdG8gYWxzbyB0YWtlIGNhcmUg d2hlbiByZWdpb25zIG92ZXJsYXAgYW5kIGF2b2lkCj4gPiA+IHVuZGVmaW5lZCBiZWhhdmlvci4K PiA+IAo+ID4gSGkgTmljaywKPiA+IAo+ID4gSGVyZSBpcyBzb210aGluZyBmcm9tIG1hbiBtZW1j cHk6Cj4gPiAKPiA+ICJ2b2lkICptZW1jcHkodm9pZCBkZXN0W3Jlc3RyaWN0IC5uXSwgY29uc3Qg dm9pZCBzcmNbcmVzdHJpY3QgLm5dLAo+ID4gICAgICAgICAgICAgICAgICAgICAgc2l6ZV90IG4p Owo+ID4gCj4gPiBUaGUgIG1lbWNweSgpICBmdW5jdGlvbiBjb3BpZXMgbiBieXRlcyBmcm9tIG1l bW9yeSBhcmVhIHNyYyB0byBtZW1vcnkgYXJlYSBkZXN0Lgo+ID4gVGhlIG1lbW9yeSBhcmVhcyBt dXN0IG5vdCBvdmVybGFwLiAgVXNlIG1lbW1vdmUoMykgaWYgdGhlIG1lbW9yeSBhcmVhcyBkbyAg b3ZlcuKAkAo+ID4gbGFwLiIKPiA+IAo+ID4gSU1ITywgdGhlICJyZXN0cmljdCIgaW1wbGllcyB0 aGF0IHRoZXJlJ3Mgbm8gb3ZlcmxhcC4gSWYgb3ZlcmxhcAo+ID4gaGFwcGVucywgdGhlIG1hbnVh bCBkb2Vzbid0IHNheSB3aGF0IHdpbGwgaGFwcGVuLgo+ID4gCj4gPiAgRnJvbSBhbm90aGVyIHNp ZGUsIEkgaGF2ZSBhIGNvbmNlcm46IGN1cnJlbnRseSwgb3RoZXIgYXJjaCBkb24ndCBoYXZlCj4g PiB0aGlzIGFsaWFzIGJlaGF2aW9yLCBJSVVDKGF0IGxlYXN0LCBwZXIgbXkgdW5kZXJzdGFuZGlu ZyBvZiBhcm0gYW5kIGFybTY0Cj4gPiBtZW1jcHkgaW1wbGVtZW50YXRpb25zKXRoZXkganVzdCBj b3B5IGZvcndhcmQuIEkgd2FudCB0byBrZWVwIHNpbWlsYXIgYmVoYXZpb3IKPiA+IGZvciByaXNj di4KPiA+IAo+ID4gU28gSSB3YW50IHRvIGhlYXIgbW9yZSBiZWZvcmUgZ29pbmcgdG93YXJkcyBh bGlhcy1tZW1jcHktdG8tbWVtbW92ZSBkaXJlY3Rpb24uCj4gPiAKPiA+IFRoYW5rcwo+IAoKSGkg TmljaywKCj4gSWYgeW91IHJlYWQgTWF0dGVvJ3Mgb3JpZ2luYWwgcG9zdCB0aGF0IHdhcyBhbHNv IGhpcyBzdWdnZXN0aW9uLCBhbmQgTGludXMKCkkgZGlkIHJlYWQgYWxsIGRpc2N1c3Npb25zIGlu IE1hdHRlbydzIHYxIH4gdjUgYmVmb3JlIHRoaXMgcmVuZXcuIFBlciBteQp1bmRlcnN0YW5kaW5n LCBNYXR0ZW8gYWxzbyBjb25jZXJuZWQgbm8gc3VjaCBtZW1jcHktYWxpYXMtbWVtbW92ZSBiZWhh dmlvcgppbiBvdGhlciBhcmNoJ3MgaW1wbGVtZW50YXRpb25zLgoKPiBoYXMgYWxzbyBjb21tZW50 ZWQgb24gdGhhdC4gSW4gZ2VuZXJhbCBpdCdzIGJldHRlciB0byBoYW5kbGUgdGhlIGNhc2Ugd2hl cmUKCkxpbnVzIGNvbW1lbnRlZCBvbiBodHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19i dWcuY2dpP2lkPTYzODQ3NyNjMTMyCmFib3V0IGdsaWJjIGFsaWFzIG1lbWNweSB0byBtZW1vdmUg cmF0aGVyIHRoYW4gdGhlIHBhdGNoIHNlcmllcy4KCj4gdGhlIHJlZ2lvbnMgcHJvdmlkZWQgdG8g bWVtY3B5KCkgb3ZlcmxhcCB0aGFuIHRvIHJlc29ydCB0byAidW5kZWZpbmVkCj4gYmVoYXZpb3Ii LCBJIHByb3ZpZGVkIGEgYmFja3dhcmRzIGNvcHkgZXhhbXBsZSB0aGF0IHlvdSBjYW4gdXNlIHNv IHRoYXQgd2UKPiBjYW4gaGF2ZSBib3RoIGZ3IGFuZCBidyBjb3B5aW5nIGZvciBtZW1tb3ZlKCks IGFuZCB1c2UgbWVtbW92ZSgpIGluIGFueQo+IGNhc2UuIFRoZSBbcmVzdHJpY3QgLm5dIGluIHRo ZSBwcm90b3R5cGUgaXMganVzdCB0aGVyZSB0byBzYXkgdGhhdCB0aGUgc2l6ZQo+IG9mIHNyYyBp cyByZXN0cmljdGVkIGJ5IG4gKHRoZSBuZXh0IGFyZ3VtZW50KS4gSWYgc29tZW9uZSB1c2VzIG1l bWNweSgpIHdpdGgKCkkgZGlkbid0IGhhdmUgYzk5IHNwZWMgaW4gaGFuZCwgYnV0IEkgZm91bmQg Z2NjIGV4cGxhbmF0aW9ucyBhYm91dApyZXN0cmljdCBrZXl3b3JkIGZyb20gWzFdOgoKInRoZSBy ZXN0cmljdCBkZWNsYXJhdGlvbiBwcm9taXNlcyB0aGF0IHRoZSBjb2RlIHdpbGwgbm90IGFjY2Vz cyB0aGF0Cm9iamVjdCBpbiBhbnkgb3RoZXIgd2F5LS1vbmx5IHRocm91Z2ggcC4iCgpTbyBpZiB0 aGVyZSdzIG92ZXJsYXAgaW4gbWVtY3B5LCB0aGVuIGl0IGNvbnRyYWRpY3RzIHRoZSByZXN0cmlj dAppbXBsaWNhdGlvbi4KClsxXSBodHRwczovL3d3dy5nbnUub3JnL3NvZnR3YXJlL2MtaW50cm8t YW5kLXJlZi9tYW51YWwvaHRtbF9ub2RlL3Jlc3RyaWN0LVBvaW50ZXJzLmh0bWwKCkFuZCBmcm9t IHRoZSBtYW51YWwsIGlmIHRoZSBtZW1jcHkgdXNlcnMgbXVzdCBlbnN1cmUgIlRoZSBtZW1vcnkg YXJlYXMKbXVzdCBub3Qgb3ZlcmxhcC4iIFNvIEkgdGhpbmsgYWxsIGxpbnV4IGtlcm5lbCdzIG1l bWNweSBpbXBsZW1lbnRhdGlvbnMob25seSBjb3B5CmZ3IGFuZCBkb24ndCB0YWtlIG92ZXJsYXAg aW50byBjb25zaWRlcmF0aW9uKSBhcmUgcmlnaHQuCgpJIGRpZCBzZWUgdGhlIGFsaWFzLW1lbWNw eS1hcy1tZW1tb3ZlIGluIHNvbWUgbGliYyBpbXBsZW1lbnRhdGlvbnMsIGJ1dAp0aGlzIGlzIG5v dCB0aGUgc3R5bGUgaW4gY3VycmVudCBrZXJuZWwncyBpbXBsZW1lbnRhdGlvbnMuCgpHaXZlbiBj dXJyZW50IHJpc2N2IGFzbSBpbXBsZW1lbnRhdGlvbiBhbHNvIGRvZXNuJ3QgZG8gdGhlIGFsaWFz IGFuZApjb3B5LWZ3IG9ubHksIGFuZCB0aGlzIHNlcmllcyBpbXByb3ZlcyBwZXJmb3JtYW5jZSBh bmQgZG9lc24ndCBpbnRyb2R1Y2UgdGhlCklzIGl0IGJldHRlciB0byBkaXZpZGUgdGhpcyBpbnRv IHR3byBzdGVwczogRmlyc3RseSwgbWVyZ2UgdGhpcyBzZXJpZXMKaWYgdGhlcmUncyBubyBvYnZp b3VzIGJ1Zzsgc2Vjb25kbHksIGRvIHRoZSBhbGlhcyBhcyB5b3Ugc3VnZ2VzdGVkLApzaW5jZSB5 b3UgaGF2ZSBhIGJhc2ljIGltcGxlbWVudGF0aW9uLCB5b3UgY291bGQgZXZlbiBzdWJtaXQgeW91 ciBwYXRjaAo7KSBXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGlzIHR3byBzdGVwcyBzb2x1dGlv bj8KClRoYW5rcwo+IG92ZXJsYXBwaW5nIHJlZ2lvbnMsIHdoaWNoIGlzIGFsd2F5cyBhIHBvc3Np YmlsaXR5LCBpbiB5b3VyIGNhc2UgaXQnbGwKPiByZXN1bHQgY29ycnVwdGVkIGRhdGEsIHdlIHdv bid0IGV2ZW4gZ2V0IGEgd2FybmluZyAoc3RpbGwgY291bnRzIGFzCj4gdW5kZWZpbmVkIGJlaGF2 aW9yKSBhYm91dCBpdC4KPiAKPiBSZWdhcmRzLAo+IE5pY2sKPiAKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJpc2N2IG1haWxpbmcgbGlzdAps aW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 189513D964 for ; Wed, 31 Jan 2024 05:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706679494; cv=none; b=hURfWT/GU8d9tmszqHcCTXFesULAcgaynsSrxm5owB8lvz4j2/PK/ShSEbHqlLGsIdS62kGoQWhipFZAnbstcJR+zieyEMapwnZT4aXuuBqqMOujnBwV6PkjQ8TnFzJJSod8oX5BUjXLwwuE7xh+991xwxNv26RPR5AjjUiU3wE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706679494; c=relaxed/simple; bh=22Krx4btf00/8e1ZZBBu8MzhsLLX45dV/yNclvUWUag=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aPO7kBClBPSga/yw1USJQrMW4bYqTmgrjJg1NbZ4lqLj5K644hwea8XuNlS18qO48UFny230BxuiVbDR7RslhbqRH5wn0Y8ulNutlLVg6nzP5LEF+5iKyNN0lDUutzDhaFaHTRVI6+Yu138+B4JiVtOOPYcC2k2siP4A9no2f3M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SprPIEde; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SprPIEde" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB433C43390; Wed, 31 Jan 2024 05:38:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706679493; bh=22Krx4btf00/8e1ZZBBu8MzhsLLX45dV/yNclvUWUag=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SprPIEdeeiOm1uug0/HcOCQDu8xShAIOqfy+Lr8SVYVikVDl3aI9ONVCm1PDroLb1 /BBHiEG3trPAcQac98allr6kqurTPWi3T/1CU/PDwPa5WreOBblJ06FFQG63/iXQK8 c1pDO19/jRPVQ2ZTmkW4gLUv20otv3aiF+NVanjiOKc1j95D4q0k0APJIt0a7JLLw/ VvaqDj03CMt0Z19iCHhUPPiRIZp5JLNPh4DEVmUjvSJtsDDzHIOE/gen0ZBU8Z+FCC iLPTFwl638xcT/bFSayT0AriKuzt6aMpfFNTa6R6FJXhcleU9ee3OTpMF8Of7QEF19 rsNbZ5uKJN0Zg== Date: Wed, 31 Jan 2024 13:25:10 +0800 From: Jisheng Zhang To: Nick Kossifidis Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Matteo Croce , kernel test robot Subject: Re: [PATCH 2/3] riscv: optimized memmove Message-ID: References: <20240128111013.2450-1-jszhang@kernel.org> <20240128111013.2450-3-jszhang@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jan 30, 2024 at 06:52:24PM +0200, Nick Kossifidis wrote: > On 1/30/24 15:12, Jisheng Zhang wrote: > > On Tue, Jan 30, 2024 at 01:39:10PM +0200, Nick Kossifidis wrote: > > > On 1/28/24 13:10, Jisheng Zhang wrote: > > > > From: Matteo Croce > > > > > > > > When the destination buffer is before the source one, or when the > > > > buffers doesn't overlap, it's safe to use memcpy() instead, which is > > > > optimized to use a bigger data size possible. > > > > > > > > Signed-off-by: Matteo Croce > > > > Reported-by: kernel test robot > > > > Signed-off-by: Jisheng Zhang > > > > > > I'd expect to have memmove handle both fw/bw copying and then memcpy being > > > an alias to memmove, to also take care when regions overlap and avoid > > > undefined behavior. > > > > Hi Nick, > > > > Here is somthing from man memcpy: > > > > "void *memcpy(void dest[restrict .n], const void src[restrict .n], > > size_t n); > > > > The memcpy() function copies n bytes from memory area src to memory area dest. > > The memory areas must not overlap. Use memmove(3) if the memory areas do over‐ > > lap." > > > > IMHO, the "restrict" implies that there's no overlap. If overlap > > happens, the manual doesn't say what will happen. > > > > From another side, I have a concern: currently, other arch don't have > > this alias behavior, IIUC(at least, per my understanding of arm and arm64 > > memcpy implementations)they just copy forward. I want to keep similar behavior > > for riscv. > > > > So I want to hear more before going towards alias-memcpy-to-memmove direction. > > > > Thanks > Hi Nick, > If you read Matteo's original post that was also his suggestion, and Linus I did read all discussions in Matteo's v1 ~ v5 before this renew. Per my understanding, Matteo also concerned no such memcpy-alias-memmove behavior in other arch's implementations. > has also commented on that. In general it's better to handle the case where Linus commented on https://bugzilla.redhat.com/show_bug.cgi?id=638477#c132 about glibc alias memcpy to memove rather than the patch series. > the regions provided to memcpy() overlap than to resort to "undefined > behavior", I provided a backwards copy example that you can use so that we > can have both fw and bw copying for memmove(), and use memmove() in any > case. The [restrict .n] in the prototype is just there to say that the size > of src is restricted by n (the next argument). If someone uses memcpy() with 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 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? Thanks > overlapping regions, which is always a possibility, in your case it'll > result corrupted data, we won't even get a warning (still counts as > undefined behavior) about it. > > Regards, > Nick >