On Wed, 17 Jun 2026, Liu, Hongtao wrote: > > > > -----Original Message----- > > From: Richard Biener <[email protected]> > > Sent: Tuesday, June 16, 2026 10:00 PM > > To: [email protected] > > Cc: Liu, Hongtao <[email protected]> > > Subject: [PATCH 3/3] [x86] use recorded vector composition type for costing > > > > We're making vector construction extra costly but too much because we up to > > now do not know the actual vector composition type used. This makes use of > > this now available information. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > > > OK? > > > > Thanks, > > Richard. > > > > * config/i386/i386.cc (ix86_vector_costs::add_stmt_cost): > > Use vector construction scaling also for mult-lane > > VMAT_STRIDED_SLP but use vector composition type recorded > > to avoid excessive over-costing. > > --- > > gcc/config/i386/i386.cc | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index > > bd0ecfddbbc..4aa57f08dce 100644 > > --- a/gcc/config/i386/i386.cc > > +++ b/gcc/config/i386/i386.cc > > @@ -26730,15 +26730,20 @@ ix86_vector_costs::add_stmt_cost (int count, > > vect_cost_for_stmt kind, > > if ((kind == vec_construct || kind == vec_to_scalar) > > && ((node > > && (((SLP_TREE_MEMORY_ACCESS_TYPE (node) == > > VMAT_ELEMENTWISE > > - || (SLP_TREE_MEMORY_ACCESS_TYPE (node) == > > VMAT_STRIDED_SLP > > - && SLP_TREE_LANES (node) == 1)) > > + || SLP_TREE_MEMORY_ACCESS_TYPE (node) == > > VMAT_STRIDED_SLP) > > && (TREE_CODE (DR_STEP (STMT_VINFO_DATA_REF > > (SLP_TREE_REPRESENTATIVE > > (node)))) > > != INTEGER_CST)) > > || mat_gather_scatter_p (SLP_TREE_MEMORY_ACCESS_TYPE > > (node)))))) > > { > > - stmt_cost = ix86_default_vector_cost (kind, mode); > > - stmt_cost *= (TYPE_VECTOR_SUBPARTS (vectype) + 1); > > + auto lsdata = static_cast<vect_load_store_data *> (node->data); > > + tree ls_type = lsdata->ls_type ? lsdata->ls_type : vectype; > > + tree ls_eltype > > + = lsdata->ls_eltype ? lsdata->ls_eltype : TREE_TYPE (ls_type); > > + stmt_cost = ix86_vector_cd_cost (TYPE_MODE (ls_type), > > + TYPE_MODE (ls_eltype)); > > It will mistakenly use vector construction cost for kind == > vec_to_scalar(scalarized stores for elementwise/strided memory accesses with > non-constant DR_STEP)
That's on purpose, it's either full vector composition or full vector decomposition and ix86_vector_cd_cost models both (ix86_vector_construct_deconstruct_cost). So yes, previously we've costed deconstruction in a too simplistic way, but yes, I think you are correct to the extent that we'll get one 'count' for each element extracted leading to inflated cost. I'll see how to fix that. Thanks for catching. Richard. > > > + stmt_cost *= (GET_MODE_BITSIZE (TYPE_MODE (ls_type)) > > + / GET_MODE_BITSIZE (TYPE_MODE (ls_eltype)) + 1); > > } > > else if ((kind == vec_construct || kind == scalar_to_vec) > > && node > > -- > > 2.51.0 > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
