Thank you for all suggestions above. > > I see. So this clearly is a feature on instructions then, not modes. > > In fact it might be profitable to use unpredicated add to avoid > > computing the loop mask for a specific element width completely even > > when that would require more operation for a wide SVE implementation. > > > > For the patch at hand I would suggest to re-post without a new target > > hook, ignoring the -msve-vector-bits complication for now and simply > > key on GET_MODE_SIZE being POLY_INT, having a vectorizer local helper > > like > > > > tree > > get_fixed_size_vectype (tree old_vectype, unsigned nlanes-upper-bound) > > I can see the attraction of that, but it doesn't seem to be conceptually > a poly-int vs. fixed-size thing. > > If a new hook seems like too much, maybe an alternative would be > to pass an optional code_helper to TARGET_VECTORIZE_RELATED_MODE? > That's the hook that we already use for switching between vector modes > in a single piece of vectorisation.
I could try moving forward with no new target hook introduced. But I'd like to clarify that besides -msve-vector-bits complication, there are still a couple of target-dependent things in my current aarch64_find_subvector_type() that need to be figured out how to do it in an alternative way. 1) In my current patch, I also checked "(vec_flags & VEC_PARTIAL)". This check is a must as the vectorizer may use SVE as partial vectors, in which elements in the vector are not consecutive. The number of lanes is not equal to niters in this case so we cannot simply replace SVE by AdvSIMD. 2) Respecting AARCH64_AUTOVEC_SVE_ONLY. This option restricts vectorization to SVE only, and I wanted to ensure that my patch respects it appropriately. If you have any recommendations on how to do this in a clean target-independent way, please let me know. -- Thanks, Pengfei
