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.
I'm equally unsure about the IFN_PREDICATED_INDEX_UPDATE unless it's supposed to be a popcount-like operation. 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 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?). 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? 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
