Hi Richard,
on 2021/1/15 下午8:03, Richard Biener wrote:
> On Fri, Jan 15, 2021 at 9:11 AM Kewen.Lin <li...@linux.ibm.com> wrote:
>>
>> Hi,
>>
>> This patch follows Richard's suggestion in the thread discussion[1],
>> it's to factor out the nloads computation in vectorizable_load for
>> strided access, to ensure we can obtain the consistent information
>> when estimating the costs.
>>
>> btw, the reason why I didn't try to save the information into
>> stmt_info during analysis phase and then fetch it in transform phase
>> is that the information is just for strided slp loading, and to
>> re-compute it looks not very expensive and acceptable.
>>
>> Bootstrapped/regtested on powerpc64le-linux-gnu P9,
>> x86_64-redhat-linux and aarch64-linux-gnu.
>>
>> Is it ok for trunk? Or it belongs to next stage 1?
>
> First of all I think this is stage1 material now. As we now do
> SLP costing from vectorizable_* as well I would prefer to have
> vectorizable_* be structured so that costing is done next to
> the transform. Thus rather than finish the vectorizable_*
> function when !vec_stmt go along further but in places where
> code is generated depending on !vec_stmt perform costing.
> This makes it easier to keep consting and transform in sync
> and match up. It might not be necessary for the simple
> vectorizable_ functions but for loads and stores there are
> so many paths through code generation that matching it up
> with vect_model_{load/store}_cost is almost impossible.
>
Thanks for the comments! Your new suggestion sounds better,
I'll update the patch according to this.
BR,
Kewen
