Yeah, I am not insisting it must honor the type, but I am not sure we should move this in that way now, it seems possible to make a vector mode legal but still split by controlling optab_supported_p I think.
The issue with the ABI is that the modes are not available at all right now I suppose? And that's due to riscv-vector-switch using vls_mode_valid_p? Or is there something else that complicates things (just from an ABI perspective)?
I guess we could ditch vls_mode_valid_p in riscv-vector-switch altogether to have the modes available but no operations with them. We'd probably need to ensure that we at least have a TARGET_MIN_VLEN in the mode requirements, though.
For "GCC vector" deconstruction IIRC forwprop (and maybe other places) just check for pure mode availability and not a specific optab when doing constructor optimizations. So for those cases we would need to provide custom fallbacks in the backend. But if I'm not missing something I don't think there's a lot more to it?
However I think this should be related straightforwardly since it kinda much fits what we claim in the document, also as you say, it has more room to play with it, so I incline fix/change that in this way and then introduce other options to address that later? (I assume at least defer until we introduce prefered LMUL in tune_param) What do you think?
Is the suggestion to have another param at some point that controls LMUL for "GCC vectors"? And then have both in a tune struct rather than just rvv-max-lmul?
-- Regards Robin
