[llvm-dev] Questions about vscale

[Renato Golin via llvm-dev]

On Tue, 7 Apr 2020 at 09:30, Kai Wang via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>           LMUL = 1           LMUL = 2            LMUL = 4            LMUL = 8
> int64_t | vscale x 1 x i64 | vscale x  2 x i64 | vscale x  4 x i64 | vscale x  8 x i64
> int32_t | vscale x 2 x i32 | vscale x  4 x i32 | vscale x  8 x i32 | vscale x 16 x i32
> int16_t | vscale x 4 x i16 | vscale x  8 x i16 | vscale x 16 x i16 | vscale x 32 x i16
>  int8_t | vscale x 8 x i8  | vscale x 16 x i8  | vscale x 32 x i8  | vscale x 64 x i8
>
> We have another architecture parameter, ELEN, which means the maximum size of a single vector element in bits.

Hi,

For my own education, some quick questions:

1. is LMUL always a multiple of ELEN?
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?


> We hope the type system could be consistent under ELEN = 32 and ELEN = 64. However, vscale may be a fractional value under ELEN = 32 in the above type system. When ELEN = 32, i64 is an invalid type (we could ignore the first row for ELEN = 32) and vscale may become 1/2 on run time to fit the architecture (if the vector register only has 32 bits).

Do you mean ELEN=32 like this?
int32_t | vscale x 1 x i32 | vscale x 2 x i32 | vscale x  4 x i32 |
vscale x  8 x i32
int16_t | vscale x 2 x i16 | vscale x 4 x i16 | vscale x  8 x i16 |
vscale x 16 x i16
  int8_t | vscale x 4 x i8   | vscale x 8 x i8   | vscale x 16 x  i8 |
vscale x 32 x i8

If the type is invalid, you would need to legalise it, and in that
case create some cluttered accessors (via insert/extract element) and
possibly use intrinsics to expose underlying instructions that can
deal with it.

Perhaps I'm not clear on what you need, but vscale is supposed to be
the number of valid elements (lanes), and given i64 is invalid, vscale
wouldn't apply?

> Is there any problem to assume vscale to be fractional under some circumstances? vscale should be an unknown value when compiling. So, it should have no impact on code generation and optimization. The relationship between types is correct regardless vscale’s value. Is there anything I missed?

I believe the assumption was always that vscale is an integer.
Representing it as a fraction would need code change for sure, but
also reevaluate the assumptions.

I'm copying some SVE and LV people to give a more informed opinion.

cheers,
--renato