[Bug target/121412] AArch64 SVE VLS vs VLA ICE building Pytorch with LTO

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412

--- Comment #12 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to rguenther@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.