Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   zhangfei <zhang_fei_0403@163.com>
To:     ajones@ventanamicro.com
Cc:     aou@eecs.berkeley.edu, linux-kernel@vger.kernel.org,
        linux-riscv@lists.infradead.org, palmer@dabbelt.com,
        paul.walmsley@sifive.com, zhang_fei_0403@163.com,
        zhangfei@nj.iscas.ac.cn
Subject: Re: [PATCH] riscv: Optimize memset 
Date:   Wed, 10 May 2023 11:52:43 +0800
Message-Id: <20230510035243.8586-4-zhang_fei_0403@163.com>
In-Reply-To: <20230510035243.8586-1-zhang_fei_0403@163.com>
References: <20230509-b0dc346928ddc8d2b5690f67@orel>
 <20230510035243.8586-1-zhang_fei_0403@163.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

From: zhangfei <zhangfei@nj.iscas.ac.cn>

On Tue, May 09, 2023 11:16:33AM +0200, Andrew Jones wrote: 
> On Tue, May 09, 2023 at 10:22:07AM +0800, zhangfei wrote:
> > 
> > Hi,
> > 
> > I filled head and tail with minimal branching. Each conditional ensures that 
> > all the subsequently used offsets are well-defined and in the dest region.
> 
> I know. You trimmed my comment, so I'll quote myself, here
> 
> """
> After the check of a2 against 6 above we know that offsets 6(t0)
> and -7(a3) are safe. Are we trying to avoid too may redundant
> stores with these additional checks?
> """
> 
> So, again. Why the additional check against 8 above and, the one you
> trimmed, checking 10?

Hi,

These additional checks are to avoid too many redundant stores. 

Adding a check for more than 8 bytes is because after the loop 
segment '3' comes out, the remaining bytes are less than 8 bytes, 
which also avoids redundant stores.

Thanks,
Fei Zhang