[llvm-dev] Questions about vscale

[Renato Golin via llvm-dev]

On Tue, 7 Apr 2020 at 12:51, Hanna Kruppe <hanna.kruppe at gmail.com> wrote:
> > 1. is LMUL always a multiple of ELEN?
> This happens to be true (at least in the current spec, disregarding
> some in-progress proposals) just because both are powers of two and
> the largest possible LMUL equals the smallest possible ELEN (8), but I
> don't think there is any meaning to be found in this observation. The
> two values govern unrelated aspects of the vector unit.

Sorry, I meant multiple of basic types. But you have answered my question. :)

> > 2. Is this fixed on the hardware, depending on the actual lengths, or
> > is this dynamically set by software (on a register or status flag)?
> > 2a. If dynamic, can it change from program to program? Function to function?
> It's not clear whether by "this" you mean ELEN, LMUL, or something
> else. ELEN is fixed in hardware. LMUL is a property of each individual
> instruction.

Sorry again, "this" as in both ELEN and LMUL and their relationship. Ack.

> I don't know what "vscale wouldn't apply" is supposed to mean.

Legalisation-wise, you got right, like <n x 0.5 x i64> is invalid and
gets converted to <n x 1 x i32>, which it is.

"Wouldn't apply" as in "what would be the point of having half-scale
on a type that needs to be broken in half", and thus making it whole.
You explain better below, so ignore it for now.

> But how? If we take Kai's table as gospel and look at a VLEN = ELEN =
> 32 machine, the vector type <vscale x 2 x i32> is supposed to map to a
> single vector register, which is 32b small, and thus <vscale x 2 x
> i32> would have just one element in this context (matching the "vscale
> = 1/2" intuition). To be consistent with this, <vscale x 1 x i32>
> would have be contain just *half* an element. This is not something
> any legalization strategy can achieve, because it is a fundamentally
> impossible notion. So we end up in a situation where some types are
> not just illegal and have to be legalized, but are contradictory and
> can't be legalized in any meaningful way.

Right, we have faced that problem before on non-scalable vector extensions.

For example, vectorising 3 operations in a 4-wide vector and adding an
undef in the last lane.

It didn't use to be possible to do that, many years ago, as a general
case. But if you look at register aliasing (VFP and NEON in ARMv7), we
had the idea of different number of elements on the same register,
depending on how you look.

I'm not proposing to create all combinations of half-vscale shadowing,
but perhaps adding half-length types as valid and lowering them in a
special way could work much simpler than changing the interpretation
of vscale.

Also, I'm acting like devil's advocate, so don't take my comments as a
rejection of your proposal, I'm just trying to understand where you
are coming from.

cheers,
--renato