On Fri, Jul 3, 2026 at 6:51 PM Robin Dapp <[email protected]> wrote: > > Hi Raghesh, > > RVV has a vcompress.m (reg-reg), aarch64 has compact (also reg-reg I believe). > Therefore, I'd prefer to keep the implementation a bit more general and think > a > scatter is not necessarily the best way to model this. In particular as the > final store is contiguous and only the compress operation before it is > "special". We might have a fallback from a "compress + regular store" to a > scatter but it would involve creating the scatter index vector from the mask > and not DR properties. That in itself sounds tricky at best, in particular as > we'd be in the vectorizable-store part of vectorization.
But isn't this a matter of code generation only? At least for the scalar code source to be vectorized I see no way to elide the store. Do we have to expose the detail in how the target performs a mask_len_compress_store? I assume with reg-reg compress you'll have to compress the mask as well to then perform a mask store (or popcnt + len store), the DR advacement by popcnt is the same. > I'm equally unsure about the IFN_PREDICATED_INDEX_UPDATE unless it's supposed > to be a popcount-like operation. I assume it's that, but possibly at the wrong abstraction. It should be popcnt on a mask, required for the DR update. > What I think can be reused is the gather/scatter analysis part that fires when > the DR is not scev-analyzable like with the data-dependent 0/1 step in your > motivating example. > My take is that we rather want a new vectorizable_compaction/compression (or > however we want to call it) entirely. Also, I'd argue for IFN_VCOMPRESS to be > the main driver and IFN_VCOMPRESS_STORE to be handled separately, maybe via > isel (IFN_VCOMPRESS + store = IFN_VCOMPRESS_STORE)? I see how mask_len_compress_store might be semantically awful, having len/mask already compressed and an additional mask that compresses the source. x86 also has reg-reg compress in addition to the memory destination case - I suppose that can be fused in the backend. > I think (it's more of a guess for now) a viable structure could look like: > > vect_analyze_scalar_cycles analyzes the phi cycle and set a new def type > (maybe > vect_compress_def instead of predicated_phi_def?). vect_cond_induction_def? > I don't think the analysis > needs to be overly complicated, we must just only ensure that, looking through > conversion, it's +0 or +1. I also believe we would need to ensure there is no > wrapping involved, otherwise we'd be back at the gather/scatter modelling. > Either ranger can help or we need a versioning assumption. (I'm working on > scev assumptions right now.) That's basically your predicated_index_plus_one, > perhaps with some simplifications. > > Most of the other analysis I would hope vect_check_gather_scatter already > handles for us. > > vectorizable_compression? would classify the involved statements, check masks, > target support for popcount on mask etc. > > vectorizable_store needs a new VMAT like VMAT_COMPRESS that comes into effect > after the gather/scatter detection ran. vect_check_gather_scatter should > strip > scale and conversions already and in gs_info.offset we would need to see the > PHI (or something very close to it) eventually. If that phi has a def_type == > vect_compress_def, we can set VMAT_COMPRESS. During codegen we just need to > get to cnt = popcount (mask). That would need to be a new "thing" as well. > The length or mask of the final store is kind of independent of the ordinary > loop control, so maybe vect_get_compress_length or something, that we stored > before via popcount etc? Separating compression from storing is difficult since we only have a single scalar stmt (and SLP node, at least unless we split that) to analyze/transform. Given that scalar stmt is a store (or a load for decompress) I'd have vectorizable_store drive this. But sure, with a new VMAT_COMPRESS_DECOMPRESS (though we didn't add VMAT_STRIDED for strided stores but made those re-use gather/scatter). > > That's my very high-level brain-stormed idea and I glossed over many details. > My biggest concern is that most of what I assumed depends on the IFN path of > gather/scatter and x86 only has the legacy path :/ > > -- > Regards > Robin >
