https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112420
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 7 Nov 2023, juzhe.zhong at rivai dot ai wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112420 > > --- Comment #2 from JuzheZhong <juzhe.zhong at rivai dot ai> --- > (In reply to Richard Biener from comment #1) > > We end up using gathers for the strided load which would be OK and avoid the > > issue noted in the comment. Thus we get true from > > vect_use_strided_gather_scatters_p (). That has a comment guard: > > > > /* As a last resort, trying using a gather load or scatter store. > > > > ??? Although the code can handle all group sizes correctly, > > it probably isn't a win to use separate strided accesses based > > on nearby locations. Or, even if it's a win over scalar code, > > it might not be a win over vectorizing at a lower VF, if that > > allows us to use contiguous accesses. */ > > if (*memory_access_type == VMAT_ELEMENTWISE > > && single_element_p > > && loop_vinfo > > && vect_use_strided_gather_scatters_p (stmt_info, loop_vinfo, > > masked_p, gs_info)) > > Thanks Richi. > > So, do you mean I need to fix test to fix the FAIL? > > Is this following reasonable ? Yes. Adding a scan for the "using gather/scatter for strided/grouped accesses" for riscv might be good as well, explaining things a bit. > /* { dg-final { scan-tree-dump-times "vectorized 0 loops in function" 2 "vect" > target {! riscv*-*-* } } } */
