Scalable vector types

What the type says

<vscale x 2 x float> holds vscale * 2 floats. vscale is a power of two, identical for every scalable type in the program, and unknown at compile time.

The RISC-V backend fixes its meaning: vscale is VLEN/64, because LLVM supports ELEN 32 and 64 only. At VLEN=256, vscale is 4, so <vscale x 2 x float> is eight floats and 256 bits. LMUL falls out of the lane count and the element width:

LMUL = N * sizeof(T) / 8

At f32 that makes <vscale x 1 x float> half a register (mf2), <vscale x 2 x float> one (m1), and <vscale x 4 x float> two (m2). Mask types track the same SEW/LMUL ratio, so <vscale x 2 x float> is masked by <vscale x 2 x i1>: one bit per lane, packed.

Asking for the number

%vscale = call i32 @llvm.vscale()      ; VLEN/64
%lanes  = mul i32 %vscale, 2           ; lanes in <vscale x 2 x float>
%bytes  = mul i32 %lanes, 4

The call does not fold. Anything sized from it stays runtime work: a stack buffer, a trip count, a pointer bump. That is the trade. One binary runs at VLEN=128 and VLEN=512 because the trip count comes from vl, and in exchange nothing about the vector is a compile-time constant.

Confirm the intrinsic and the type rules against your pinned release. llvm.vscale has returned i32 for a long time, but how the target derives its minimum vscale from the -march string is release-bound, and a hand-written .ll file may need a vscale_range attribute before the backend will bound the type size.

Things that break

Writing a type whose LMUL exceeds 8. <vscale x 128 x float> is LMUL=64, no register class holds it, and every operation splits into eight: legal, slow, and invisible at the source. The other failure is units. Multiplying vscale by the element width gives bytes, not lanes; sizing a buffer with the 2 from the type gives lanes at VLEN=64 and a quarter of the lanes at VLEN=256.