On Wed, 26 Aug 2026, Richard Biener wrote: > > This shows a more complicated case to defend against invariant > computations inside the loop. There's no easy place to stick LIM > apart from adding a separate pass which then could be disabled, > re-creating the issue. As the issue at hand appears in a pattern > stmt it's also not possible to address this in SLP discovery, > promoting fully invariant expressions to externs. > > Meaning the following attempts to handle excess (zero-padded) > input lanes in vectoriable_lane_reducing and the transform > stage, vect_transform_reduction. > > As usual we ICE in vect_get_num_copies and the transform stage > already has other means of obtaining the actual number of input > vectors, so the first patch refactors things to avoid the former. > > Then there's vect_reduction_update_partial_vector_usage which > might be bogus (but on the caller side), I have refactored things > to make targeted fixes easier if necessary. The > vectoriable_lane_reducing case looks correct where we pair > the input vector type with the number of input vectors. The > vectorizable_reduction case looks questionable, but possibly > vectype_in is always equal (in lanes) to vectype so it doesn't > matter. > > The last patch is the fix for vectoriable_lane_reducing which > I make matching the transform phase - look at the actual > (expected) number of input vectors. > > What I did not check (due to lack of a testcase) is whether > we can actually zero-fill variable-length vectors. > vect_create_constant_vectors for those adjusts nunits and > so possibly > a) breaks my number_of_places_left_in_vector logic > for the padding, > b) will eventually use duplicate_and_interleave, > but we never checked that for the zero-padding part(?) > (IMO we should, even if redundantly, verify this in > vect_slp_analyze_node_operations where we verify > vect_get_num_copies_for_invariant) > c) the permute_results[] caching might be disrupted? > > at this point I'm hoping for test coverage. > > I need to investigate some fallout, but appreciate some feedback > on the VLA vector things above.
There were two mistakes, one typo in the last patch and an error in the first where vec_num is not equal to num because the vector input array is altered. I have fixed both and this now passes bootstrap and regtest on x86_64-unknown-linux-gnu and aarch64-linux-gnu. I'll post the updated series and push. Richard. > Thanks, > Richard. > > Richard Biener (3): > Simplify vect_transform_reduction > Refactor vect_reduction_update_partial_vector_usage > tree-optimization/126998 - avoid vect_get_num_copies on SLP inputs > > .../gcc.dg/vect/vect-reduc-dot-pr126998.c | 36 ++++++ > gcc/tree-vect-loop.cc | 117 +++++++----------- > gcc/tree-vect-slp.cc | 2 +- > gcc/tree-vectorizer.h | 2 + > 4 files changed, 85 insertions(+), 72 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/vect/vect-reduc-dot-pr126998.c > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Abhinav Puri; (HRB 36809, AG Nuernberg)
