[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