Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

[Kito Cheng <kito.cheng@gmail.com>]

Let me give more explanation why RISC-V vector need so many modes than AArch64.

The following will use "RVV" as an abbreviation for "RISC-V Vector"
instructions.

There are two key points here:

- RVV has a concept called LMUL - you can understand that as register
grouping, we can group up to 8 adjacent registers together and then
operate at once, e.g. one vadd can operate on adding two 8-reg groups
at once.
- We have segment load/store that require vector tuple types. -
AArch64 has similar stuffs on both Neon and SVE, e.g. int32x2x2_t or
svint32x2_t.

In order to model LMUL in backend, we have to the combination of
scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8
different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF,
so basically we'll have 7 (LMUL type) * 7 (scalar type) here.

Okay, let's talk about tuple type AArch64 also having tuple type, but
why is it not having such a huge number of modes? It mainly cause by
LMUL; use a concrete example to explain why this cause different
design on machine mode, using scalable vector mode with SI mode tuple
here:

AArch64: svint32_t (VNx4SI) svint32x2_t (VNx8SI) svint32x3_t (VNx12SI)
svint32x3_t (VNx16SI)

AArch64 only has up to 3-tuple, but RISC-V could have up to 8-tuple,
so we already have 8 different types for each scalar mode even though
we don't count LMUL concept yet.

RISC-V*: vint32m1_t (VNx4SI) vint32m1x2_t (VNx8SI) vint32m1x3_t
(VNx12SI) vint32m1x4_t (VNx16SI) vint32m1x5_t (VNx20SI) vint32m1x6_t
(VNx24SI) vint32m1x7_t (VNx28SI) vint32m1x8_t (VNx32SI)

Using VLEN=128 as the base type system, you can ignore it if you don't
understand the meaning for now.

And let's consider LMUL now, add LMUL=2 case here, RVV has a
constraint that the LMUL * NF(NF-tuple) must be less or equal to 8, so
we have only 3 extra modes for LMUL=2.

RISC-V*: vint32m2_t (VNx8SI) vint32m2x2_t (VNx16SI) vint32m2x3_t
(VNx24SI) vint32m2x4_t (VNx32SI)

However, there is a big problem RVV have different register constraint
for different LMUL type, LMUL <= 1 can use any register, LMUL=2 type
require register align to multiple-of-2 (v0, v2, …), and LMUL=4 type
requires register align to multiple-of-4 (v0, v4, …).

So vint32m1x2_t (LMUL=1x2) and vint32m2_t (LMUL=2) have the same size
and NUNIT, but they have different register constraint, vint32m1x2_t
is LMUL 1, so we don't have register constraint, but vint32m2_t is
LMUL 2 so it has reg. constraint, it must be aligned to multiple-of-2.

Based on the above reason, those tuple types must have separated
machine mode even if they have the same size and NUNIT.

Why Neon and SVE didn't have such an issue? Because SVE and Neon
didn't have the concept of LMUL, so tuple type in SVE and Neon won't
have two vector types that have the same size but different register
constraints or alignment - one size is one type.

So based on LMUL and register constraint issue of tuple type, we must
have 37 types for vector tuples, and plus 48 modes variable-length
vector mode, and 42 scalar mode - so we have ~140 modes now, it sounds
like still less than 256, so what happened?


RVV has one more thing special thing in our type system due to ISA
design, the minimal vector length of RVV is 32 bit unlike SVE
guarantee, the minimal is 128 bits, so we did some tricks one our type
system is we have a different mode for minimal vector length
(MIN_VLEN) is 32, 64 or large or equal to 128, this design is because
it would be more friendly for vectorizer, and also model things
precisely for better code gen.

e.g.

vint32m1_t is VNx1SI in MIN_VLEN>=32

vint32m1_t is VNx2SI in MIN_VLEN>=64

vint32m1_t is VNx4SI in MIN_VLEN>=128

So actually we will have 37 * 3 modes for vector tuple mode, and now
~210 modes now (the result is little different than JuZhe's number
since I ignore some mode isn't used in C, but it defined in machine
mode due the the current GCC will always define all possible scalar
mode for a vector mode)

We also plan to add some traditional fixed length vector types like
V2SI in future…and apparently 256 mode isn't enough for this plan :(