Richard Biener <rguent...@suse.de> writes: > On Thu, 10 Jul 2025, Richard Sandiford wrote: > >> Richard Biener <rguent...@suse.de> writes: >> > The following removes an optimization that wrongly triggers right now >> > because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be >> > computed yet. >> > >> > Testing on x86_64 didn't reveal any testsuite coverage. >> > >> > Bootstrapped and tested on x86_64-unknown-linux-gnu. >> > >> > OK? >> > >> > PR tree-optimization/120939 >> > * tree-vect-loop.cc (vect_need_peeling_or_partial_vectors_p): >> > Remove eliding an epilogue based on not computed >> > LOOP_VINFO_COST_MODEL_THRESHOLD. >> >> This regresses: >> >> FAIL: gcc.dg/torture/pr113026-1.c -O3 -fomit-frame-pointer -funroll-loops >> -fpeel-loops -ftracer -finline-functions (test for bogus messages, line 10) >> >> on aarch64-linux-gnu, with: >> >> .../pr113026-1.c:10:12: warning: writing 1 byte into a region of size 0 >> [-Wstringop-overflow=] >> .../pr113026-1.c:4:6: note: at offset 16 into destination object 'dst' of >> size 16 >> >> I haven't looked into why yet, but it does seem superficially similar >> to PR60505, which was what this code seems to have been added to fix >> (g:090cd8dc70b80183c83d9f43f1e6ab9970481efd). > > Yes. I now also see the above diagnostic (not sure why it escaped me). > > Now, the issue is this elides creating a vector epilog with 8 byte > vectors so we never vectorize when n is in [8, 16]. With the proposed > patch we'd again do that, but we also have a scalar epilog then > and warn. > > Fact is that neither LOOP_VINFO_COST_MODEL_THRESHOLD nor > LOOP_VINFO_VERSIONING_THRESHOLD are initialized when we apply > this heuristic and the actual versioning condition is > using LOOP_VINFO_VERSIONING_THRESHOLD (when not zero) > plus, when the cost model threshold and that are not ordered > and vect_apply_runtime_profitability_check_p we apply > LOOP_VINFO_COST_MODEL_THRESHOLD as well (see vect_loop_versioning). > > So besides the above mentioned missed optimization caused by > the heuristic I fear there is the chance of wrong code or at > least we are applying the heuristic at a wrong place. It > was also added before we had any epilogue vectorization.
Hmm, yeah. Seems like this went wrong with g:052204fac580b21c967e57e6285d99a9828b8fac. Before that, the test was only applied after vect_analyze_loop_costing. > What happens for the diagnostic to re-appear is that we > end up with unrolled scalar epilogues we diagnose. > > I'll re-spin with an added xfail on this testcase and re-open > the bugreport? Sounds good to me FWIW. Thanks, Richard
