On Mon, Sep 14, 2026 at 11:52 AM Liu, Hongtao <[email protected]> wrote: > > > > > -----Original Message----- > > From: Liu, Hongtao <[email protected]> > > Sent: Monday, September 14, 2026 5:45 PM > > To: H.J. Lu <[email protected]>; GCC Patches <[email protected]>; > > Uros Bizjak <[email protected]> > > Subject: RE: [PATCH v3] x86: Adjust cost for vector integer conversion > > without > > SSE4.1 > > > > > + int scale = 0; > > > + if (scalar_p) > > > + { > > > + if (stmt_info > > > + && stmt_info->stmt > > > + && gimple_code (stmt_info->stmt) == GIMPLE_ASSIGN) > > > + { > > > + tree lhs = gimple_assign_lhs (stmt_info->stmt); > > > + if (TREE_CODE (lhs) == ARRAY_REF) > > > + { > > > + tree index = TREE_OPERAND (lhs, 1); > > > + /* Two more instructions are needed to access non-zero > > > + array element. */ > > > + if (TREE_CODE (index) != INTEGER_CST > > > + || compare_tree_int (index, 0) != 0) > > > + scale = 2; > > > + } > > > + } > > > + } > > > > Not fully understand this part, why access non-zero array elements should be > > penalized with additional cost, is it testcase specific or it's general? > > > > > + else if (vector_int_conversion_p && !TARGET_SSE4_1) > > > + { > > > + /* Two instructions are needed to emulate vector integer > > > + conversions. One more instruction is needed to emulate > > > + 2-element vector conversion of QImode and HImode. */ > > > + machine_mode rhs_mode = TYPE_MODE (rhs_type); > > > + rhs_mode = GET_MODE_INNER (rhs_mode); > > > + scale = (rhs_mode == SImode || GET_MODE_NUNITS (mode) != 2 > > > + ? 2 : 3); > > > + } > > > > It's reasonable to increase cost for signed conversion w/o sse4.1, but for > > unsigned conversion it's not needed, also I don't think GET_MODE_NUNITS > > (mode) == 2 makes difference from 4/8, it looks tricky. > > > > For the original PR, you're trying to prevent vectorization for 2-elemenet > > reduction. > > Revising per-stmt cost to prevent 2-element integer vectorization may hurt > > others. > > Maybe we can add a specific heuristic to add additional cost for 2-element > > integer vectorization when vector width is less equal WORD, and this should > > solve the issue in the PR and don't regress others. > When VF is 2, vector width <= WORD, and there're cross-unit movement in the > vectorization(i.e vec_contruct/vec_deconstruct/vec_to_scalar/scalar_to_vec.) > Pentise the vectorization with extra cost
Or have something like an effective integer issue width and require the vector cost to be better than scalar cost / issue width in the finish_cost hook. I'll note that for the small testcases it's the high scalar load/store cost that gives us that much budget to eat from. > > > > > > Thanks, > > Hongtao > > > > > > -- > > H.J.
