https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Richard Biener from comment #4) > > for (...) > a[32*i] = ..; > a[32*i+1] = ..; > ... > a[32*i + 31] = ...; > > to match the number of lanes in a HW vector. It shares some of the same > issues as handling vector "scalar" types. > > One issue with vector "scalar" types is that there's no scalar defs for > the actual lanes - that's somewhat of a representational issue, but we > do use those for scheduling for example. Having the "anchor" explicitly > represented would be a first step to solve this. I've now gotten far enough to realize what the hints here were trying to say. And indeed without solving this representational issue we'd have no way to build a correct SLP tree. and because the number of defs, vf and lanes don't match at the moment I get the high unroll factor. representationally I guess the question is whether we want to track the vector "scalar" lanes using the same fields we current track normal scalar lanes. I'm leaning towards a no, and that we'd want to have a vector_stmts field next to scalar_stmts and have a vec_lanes and scalar_lanes and the current lanes values would be vec_lanes + scalar_lanes? That would make the changes in vect_build_slp_instance easier to follow but would make e.g. vect_update_slp_vf_for_node automatically do the right thing. It would also make it possible to allow combinations of scalar and vector code so that for (...) a[32*i] = ..; vec<a>[32*i+5] = ..; be possible? > It's one of the TODOs that look easy but are not. Related is to support a > fractional VF so we can re-roll I guess the fractionality would only be in the subcomponents right? i.e. in the above the scalar variants would have a fractional VF. But the overall VF should still be as is today? Just processing what your thinking around this is.
