On Wed, Sep 17, 2025 at 10:30 PM Robin Dapp <rdapp....@gmail.com> wrote: > > When trying to unify the vector_vector_composition variants I noticed that > there are even more alignment checks than when I last looked ;)
Yeah :/ I don't like the way it's done very much. Having a unified idea of a "punning" type and doing the main alignment computation with that might work better. That is, we might possibly be able to separate alignment compute from VMAT_* selection. It's also that the different VMAT_* have different abilities to deal with misalignment situations (like only the contiguous path can do re-alignment, and the ability to use smaller loads to avoid gaps also differs). Ideally we'd be able to unify VMAT_STRIDED_SLP and VMAT_CONTIGUOUS[_DOWN] somehow. I'm trying to get a hold of how to incrementally improve the mess, but when I wiggle one end it tends to break at another ... :/ > I think we would need to store at least the "punning type" as well as the > element type in ls_data. The computed alignment_support_scheme as well as > the misalignment are also used for costing later. So the VMAT_STRIDED_SLP in the end works with the "load/store vector type", for strided loads it's element type is the "punning type" (also strided-SLP and elementwise basically uses this to compose the vector from elements). So I was hoping we get away with one extra type? > Can we defer that "plastic surgery" to later? I don't think there is anything > to be gained in terms of legibility if I transplant parts of it into a helper > function that is called from get_load_store_type. And I think it would > increase the scope of the current patch too much. I can try as a follow up of > course. Yes. As said, I have difficulties producing sth nice here as well. I guess creating extra friction between us doesn't help here either ;) Unless, of course you have to happen a magic idea I have not yet thought of ;) > I think the largest remaining problem is the load permutations and how to > properly filter the ones I have in mind. Yes. > Computing the alignment twice can be avoided if we either store a fallback > vectype (that's how I did it locally) or don't bother with a fallback at all. > > Regarding ls.pun_vectype, would you want to get rid of that entirely and > "replace" vectype? (Or just in get_load_store_type?) I thought replacing > isn't possible as we have done analysis based on the old vectype already. 'vectype' is the type of the data consumers like to see, but eventually we can compute a ls_vectype that is used for the actual vector load or element load and vector composition. If that's equal to vectype then OK. We could also make it ls_type, so not necessarily a vector type, the composition type is easily inferred from this? But yes, I see how you think of two types here (and I'm fine if that simplifies things). The possibly scalar ls_type can have the appropriate alignment set on it. Richard. > -- > Regards > Robin >
