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? Thanks, Yang Yang
