https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
--- Comment #12 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #11) > On x86 we face similar issues when some vector modes start to > be supported or not supported and that affects mostly global > data and types where somee "effects" have been reflected into > per-function IL. At certain points we have to make sure to > reflect such variable properties (usually TYPE_MODE/DECL_MODE) > in the context of a function. > > But as said, I'm not sure the SVE issue is the same. Somebody > with more knowledge needs to see what is actually unexpected > and why when we ICE. I think it's a related issue, but worse. At least on x86, each (vector length x element mode) combination has its own vector mode. For SVE, the vector mode depends only on the element mode. Having a separate mode for all 6 possible lengths would lead to combinatorial explosion. It also arguably doesn't make conceptual sense to have 6 different SVE modes for each element mode when there is only one set of underlying instructions (rather than 6 sets). We also can't assume that there is some N such that all TUs will be compiled with either -msve-vector-bits=scalable or -msve-vector-bits=N. It's valid to compile different TUs with different lengths and dispatch based on the runtime length. Similarly, having one TU with -msve-vector-bits=N doesn't mean that we can apply -msve-vector-bits=N to other TUs. So yeah, there's a reason why this isn't supported yet :) I agree of course that switchable lengths would be would be a nice feature to have. But I think it would make sense to start with supporting multiple vector lengths in a single TU before considering the LTO case.
