http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #5) > Alternatively we should just remove that scan-tree-dump-times from the test > altogether, counting additions where either lhs or rhs1 of addition has > vect_ in name is quite flawed, we have lots of other vector additions that > just use anonymous SSA_NAMEs without any name (_114 etc.), but still have > vector types. > > Counting addps etc. insns doesn't work though, there are 23 before and after > the r156043 change. > > Richard, what is your preference here? Well, ! we want to check that predictive commoning did something on the ! vectorized loop, which means we have to have exactly 13 vector ! additions. which means to look at the pcom dump (and maybe enhance it). On x86_64 the interesting line in -details is "Unrolling 2 times." dumped from /* Execute the predictive commoning transformations, and possibly unroll the loop. */ if (unroll) { struct epcc_data dta; if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Unrolling %u times.\n", unroll_factor); ... } else { if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Executing predictive commoning without unrolling.\n"); execute_pred_commoning (loop, chains, tmp_vars); } a common "Executing predictive commoning on loop %d" would be possibly useful. Eventually with "on %d chains" as well. All of this even without -details and within the opt-dumping framework (MSG_OPTIMIZED_LOCATIONS).