[PATCH] rs6000: Make density_test only for vector version

[Richard Biener]

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.