https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 6 Aug 2025, rsandifo at gcc dot gnu.org wrote: > 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). I see. > 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. Yes. > 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. It is arguably the very same issue in the end. That said, -fno-lto for "mismatched" TUs is the workaroud that, unfortunately, has to be applied on the users side at this point. Adding diagnostics and not combining random target flags onto the linker command line are both improvements there.
