[PATCH] tree-optimization/98855 - redo BB vectorization costing
Richard Biener
rguenther@suse.de
Fri Feb 5 13:21:38 GMT 2021
On Fri, 5 Feb 2021, Richard Sandiford wrote:
> Richard Biener <rguenther@suse.de> writes:
> > On Fri, 5 Feb 2021, Richard Sandiford wrote:
> >> Richard Biener <rguenther@suse.de> writes:
> >> > + /* First produce cost vectors sorted by loop index. */
> >> > + auto_vec<std::pair<unsigned, stmt_info_for_cost *> >
> >> > + li_scalar_costs (scalar_costs.length ());
> >> > + auto_vec<std::pair<unsigned, stmt_info_for_cost *> >
> >> > + li_vector_costs (vector_costs.length ());
> >> > + FOR_EACH_VEC_ELT (scalar_costs, i, cost)
> >> > + {
> >> > + unsigned l = gimple_bb (cost->stmt_info->stmt)->loop_father->num;
> >> > + li_scalar_costs.quick_push (std::make_pair (l, cost));
> >> > + }
> >> > + unsigned l = li_scalar_costs[0].first;
> >>
> >> Is this just to silence an unused warning? Might be worth a comment if so
> >> (although couldn't we just use 0?).
> >
> > The issue is that not all vector_costs entries have a stmt_info so
> > this uses a random loop also used in the scalar code (that's going
> > to be the correct loop in case there's only one loop involved which
> > is probably 99% of the cases). I'mm add a comment.
>
> Hmm, OK, but I thought the comment below was saying that all such
> cases follow the relevant statement, instead of coming first.
> Is this situation specific to the first run of costs?
It's to some extent out of caution since I did not try to provoke
the situation but I think there are some paths in costing that
fail to set a stmt_info for costing of an acutal stmt. While
we do want to fix this I don't think it's appropriate to ICE
for the cases at this point.
Richard.
> Richard
>
> >
> >> > + FOR_EACH_VEC_ELT (vector_costs, i, cost)
> >> > + {
> >> > + /* We inherit from the previous SI, invariants, externals and
> >> > + extracts immediately follow the cost for the related stmt. */
> >>
> >> Looks like the comment predates s/SI/COST/.
> >
> > Indeed, will fix and push.
> >
> > Thanks,
> > Richard.
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
More information about the Gcc-patches
mailing list