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? 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