On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Hi, > > When I was investigating density_test heuristics, I noticed that > the current rs6000_density_test could be used for single scalar > iteration cost calculation, through the call trace: > vect_compute_single_scalar_iteration_cost > -> rs6000_finish_cost > -> rs6000_density_test > > It looks unexpected as its desriptive function comments and Bill > helped to confirm this needs to be fixed (thanks!). > > So this patch is to check the passed data, if it's the same as > the one in loop_vinfo, it indicates it's working on vector version > cost calculation, otherwise just early return. > > Bootstrapped/regtested on powerpc64le-linux-gnu P9. > > Nothing remarkable was observed with SPEC2017 Power9 full run. > > Is it ok for trunk?
+ /* Only care about cost of vector version, so exclude scalar version here. */ + if (LOOP_VINFO_TARGET_COST_DATA (loop_vinfo) != (void *) data) + return; Hmm, looks like a quite "random" test to me. What about adding a parameter to finish_cost () (or init_cost?) indicating the cost kind? OTOH we already pass scalar_stmt to individual add_stmt_cost, so not sure whether the context really matters. That said, the density test looks "interesting" ... the intent was that finish_cost might look at gathered data from add_stmt, not that it looks at the GIMPLE IL ... so why are you not counting vector_stmt vs. scalar_stmt entries in vect_body and using that for this metric? Richard. > BR, > Kewen > ------ > gcc/ChangeLog: > > * config/rs6000/rs6000.c (rs6000_density_test): Early return if > calculating single scalar iteration cost.
