"yangyang (ET)" <yangyang...@huawei.com> writes: > Hi, > >> -----Original Message----- >> From: Richard Sandiford [mailto:richard.sandif...@arm.com] >> Sent: Wednesday, November 4, 2020 12:15 AM >> To: yangyang (ET) <yangyang...@huawei.com> >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH 1/5] [PR target/96342] Change field "simdlen" into >> poly_uint64 >> >> "yangyang (ET)" <yangyang...@huawei.com> writes: >> > Hi, >> > >> > I have revised the patch based on your suggestions. I use multiple_p >> > instead >> of !multiple_p if the eq situation is OK to make it easier to understand. >> > >> >> >> > if (n->simdclone->inbranch) >> >> >> > this_badness += 2048; >> >> >> > int target_badness = targetm.simd_clone.usable (n); @@ >> >> >> > -3988,19 >> >> >> > +3988,19 @@ vectorizable_simd_clone_call (vec_info *vinfo, >> >> >> > +stmt_vec_info >> >> >> stmt_info, >> >> >> > arginfo[i].vectype = get_vectype_for_scalar_type (vinfo, >> >> >> > arg_type, >> >> >> > >> >> slp_node); >> >> >> > if (arginfo[i].vectype == NULL >> >> >> > - || (simd_clone_subparts (arginfo[i].vectype) >> >> >> > - > bestn->simdclone->simdlen)) >> >> >> > + || (known_gt (simd_clone_subparts (arginfo[i].vectype), >> >> >> > + bestn->simdclone->simdlen))) >> >> >> >> >> >> Here too I think we want constant_multiple_p: >> >> >> >> >> >> || !constant_multiple_p (bestn->simdclone->simdlen, >> >> >> simd_clone_subparts >> >> >> (arginfo[i].vectype)) >> >> >> >> >> > >> >> > Use multiple_p here since the multiple is not needed. >> >> >> >> True, but in the case of vectorisation, we need to generate a >> >> constant number of copies at compile time. If we don't enforce a >> >> constant multiple, we might end up trying to use an Advanced SIMD routine >> when vectorising for SVE. >> >> >> >> The reason we don't have a two-argument version of >> >> constant_multiple_p is that so far nothing has needed it (at least >> >> AFAIK). There's no conceptual problem with adding it though. I'm happy >> to do that if it would help. >> >> >> > >> > Two-argument versions of constant_multiple_p are added in the v3-patch. >> Could you please check if the added versions are OK ? >> > >> > Bootstrap and tested on both aarch64 and x86 Linux platform, no new >> regression witnessed. >> >> Looks great, thanks. Pushed to trunk. >> >> Richard > > Thanks for installing the patch. As you mentioned in the PR, stage1 of GCC 11 > is going to close in a few weeks, and > GCC Development Plan describes the stage3 as " During this two-month period, > the only (non-documentation) changes > that may be made are changes that fix bugs or new ports which do not require > changes to other parts of the compiler. > New functionality may not be introduced during this period. ". So does it > mean that the rest four patches of this feature > need to wait for the GCC 12 stage1 to get installed?
Any taret-independent patches would need to be posted by the end of next week to get into GCC 11. There's a bit more leeway for SVE-specific pieces in config/aarch64, since those have a lower impact. Thanks, Richard
