On Wed, May 17, 2023 at 8:06 AM Kewen.Lin <li...@linux.ibm.com> wrote: > > Hi, > > When working on a cost tweaking patch, I found that a newly > added test case has different dumpings with stage-1 and > bootstrapped gcc. By looking into it, the apparent reason > is vect_analyze_loop_2 doesn't get slp_done_for_suggested_uf > set expectedly, the following retrying will use the garbage > slp_done_for_suggested_uf instead. In fact, the setting of > slp_done_for_suggested_uf only happens when the previous > analysis succeeds, for the mentioned test case, its previous > analysis does fail, it's unexpected to use the value of > slp_done_for_suggested_uf any more. > > In function vect_analyze_loop_1, we only return success when > res is true, which is the result of 1st analysis. It means > we never try to vectorize with unroll_vinfo if the previous > analysis fails. So this patch shouldn't break anything, and > just stop some useless analysis early. > > Bootstrapped and regtested on x86_64-redhat-linux, > aarch64-linux-gnu and powerpc64{,le}-linux-gnu. > > Is it ok for trunk?
OK for trunk and affected branches. Richard. > BR, > Kewen > ----- > gcc/ChangeLog: > > * tree-vect-loop.cc (vect_analyze_loop_1): Don't retry analysis with > suggested unroll factor once the previous analysis fails. > --- > gcc/tree-vect-loop.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc > index ed0166fedab..905145ae97b 100644 > --- a/gcc/tree-vect-loop.cc > +++ b/gcc/tree-vect-loop.cc > @@ -3044,7 +3044,7 @@ vect_analyze_loop_1 (class loop *loop, vec_info_shared > *shared, > res ? "succeeded" : " failed", > GET_MODE_NAME (loop_vinfo->vector_mode)); > > - if (!main_loop_vinfo && suggested_unroll_factor > 1) > + if (res && !main_loop_vinfo && suggested_unroll_factor > 1) > { > if (dump_enabled_p ()) > dump_printf_loc (MSG_NOTE, vect_location, > -- > 2.31.1