Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 0/1] arm64: Accelerate Adler32 using arm64 SVE
 instructions.
To:     Dave Martin <Dave.Martin@arm.com>
CC:     <alexandre.torgue@st.com>, <catalin.marinas@arm.com>,
        <gaoguijin@huawei.com>, <colordev.jiang@huawei.com>,
        <luchunhua@huawei.com>, <linux-crypto@vger.kernel.org>,
        <mcoquelin.stm32@gmail.com>, <liliang889@huawei.com>,
        <will@kernel.org>, <davem@davemloft.net>,
        <linux-arm-kernel@lists.infradead.org>,
        <herbert@gondor.apana.org.au>
References: <20201103121506.1533-1-liqiang64@huawei.com>
 <20201105165301.GH6882@arm.com>
 <f323de50-c358-88e7-6588-7d14542f2754@huawei.com>
 <20201110104629.GJ6882@arm.com>
 <89a9bdcc-b96e-2f2d-6c52-ca44e0e3472c@huawei.com>
 <20201110160708.GL6882@arm.com>
 <484ad2c8-3905-fc98-237c-f7eb4045edbc@huawei.com>
 <20201112111745.GS6882@arm.com>
 <72514954-ea04-6aa3-73d8-bb0fc39b6de2@huawei.com>
 <20201116155636.GZ6882@arm.com>
From:   Li Qiang <liqiang64@huawei.com>
Message-ID: <ab2a10f0-82eb-8e31-f53f-0bcae6977504@huawei.com>
Date:   Tue, 17 Nov 2020 20:45:55 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <20201116155636.GZ6882@arm.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk


在 2020/11/16 23:56, Dave Martin 写道:
>> --8<--
>> 	...
>> 	adler_A .req    x10
>> 	adler_B .req    x11
>> 	
>> 	.macro	adler32_core
>> 	ld1b	zX.h, p0/z, [x1]	// load bytes
>> 	inch	x1
>>
>> 	uaddv	d0, p0, zX.h
>> 	mul	zX.h, p0/m, zX.h, zJ.h	// Sum [j=0 .. v-1] j*X[j+n]
>> 	mov	x9, v0.d[0]
>> 	uaddv	d1, p0, zX.h
>> 	add	adler_A, adler_A, x9	// A[n+v] = An + Sum [j=0 ... v-1] X[j]
>> 	mov	x9, v1.d[0]
>> 	madd	adler_B, x7, adler_A, adler_B	// Bn + v*A[n+v]
>> 	sub	adler_B, adler_B, x9		// B[n+v] = Bn + v*A[n+v] - Sum [j=0 .. v-1] j*X[j+n]
>> 	.endm
> If this has best performance, I find that quite surprising.  Those uaddv
> instructions will stop the vector lanes flowing independently inside the
> loop, so if an individual element load is slow arriuaddving then everything
> will have to wait.

I don't know much about this problem, do you mean that the uaddv instruction used in
the loop has a great impact on performance?

> 
> A decent hardware prefetcher may tend to hide that issue for sequential
> memory access, though: i.e., if the hardware does a decent job of
> fetching data before the actual loads are issued, the data may appear to
> arrive with minimal delay.
> 
> The effect might be a lot worse for algorithms that have less
> predictable memory access patterns.
> 
> Possibly you do win some additional performance due to processing twice
> as many elements at once, here.

I think so. Compared to loading bytes into zX.h, if you load them directly into zX.b,
and then use uunpklo/uunpkhi for register expansion, the performance will be more better(20% faster).
This may be the reason.

-- 
Best regards,
Li Qiang