On Thu, Sep 10, 2026 at 3:57 PM Robin Dapp <[email protected]> wrote: > > > For a strided grouped load, get_load_store_type can drop a permutation > > that selects a consecutive run of lanes and treat the run as the group, > > so VMAT_STRIDED_SLP loads it with a few wide loads instead of one scalar > > load per element. has_consecutive_load_permutation also required the > > run length to divide the group size. Once the subchain is taken the > > group size becomes the run length, and vectorizable_load's offset walk > > and gcd (group_size, nunits) depend only on that, so the requirement is > > not needed. > > Hmm, I don't really recall why I added this condition in the first place > (probably some leftover from its VMAT_STRIDED_SLP origin) but I think > it's ok to relax it. Alignment won't change as that is only dependent > on the first element and I don't think we can cause new inefficiencies > either by allowing odd-sized groups.
I suppose so. The patch is OK. > With opening the window further, though, I wonder whether it would start > to make sense to fold the group gap into the stride and reduce the group > size right away during DR analysis. I think Richi noted that a long > time ago. Then we wouldn't need to work around it here. But I don't > think that should block this patch. Right, the discrepancy is with respect to constant vs. variable strided groups - we can handle the former as VMAT_CONTIGUOUS, honoring the constant gap between loop iterations via permutes. ISTR we drop it once the gap is bigger than the number of vector lanes and then make it STMT_VINFO_STRIDED_P. Of course we shouldn't decide this at DR analysis time but rather decide at vectorizable_load time so this representational difference is a bit unfortunate. Richard. > -- > Regards > Robin >
