tree-optimization/115372 - failed store-lanes in some cases

The gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c testcase shows
that we sometimes fail to use store-lanes even though it should be
profitable.  We're currently relying on vect_slp_prefer_store_lanes_p
at the point we run into the first SLP discovery mismatch with obviously
limited information.  For the case at hand we have 3, 5 or 7 lanes
of VnDImode [2, 2] vectors with the first mismatch at lane 2 so the
new group size is 1.  The heuristic says that might be an OK split
given the rest is a multiple of the vector lanes.  Now we continue
discovery but in the end mismatches result in uniformly single-lane
SLP instances which we can handle via interleaving but of course are
prime candidates for store-lanes.  The following patch re-assesses
with the extra knowledge now just relying on the fact whether the
target supports store-lanes for the given group size.

	PR tree-optimization/115372
	* tree-vect-slp.cc (vect_build_slp_instance): Compute the
	uniform, if, number of lanes of the RHS sub-graphs feeding
	the store and if uniformly one, use store-lanes if the target
	supports that.

0 files changed, 0 insertions, 0 deletions