"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
