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

["juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>]

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

I am not sure whether aggregate type without a tuple mode can work for us.
Here is the example:

We already had a vector type "vint8mf8_t", the corresponding mode is VNx1SImode.

Now we have an intrinsic as following:
vint8mf8x2_t test_vlseg2e8_v_i8mf8(const int8_t *base, size_t vl) {
  return __riscv_vlseg2e8_v_i8mf8(base, vl);
}

This intrinsic is suppose generate a "vlseg2e8.v" instructions and dest operand of the intrinsic should be 2 continguous registers.

Another intrinsic:
 vint8mf8x3_t test_vlseg3e8_v_i8mf8(const int8_t *base, size_t vl) {
  return __riscv_vlseg3e8_v_i8mf8(base, vl);
}

This intrinsic is suppose generate a "vlseg3e8.v" instructions and dest operand of the intrinsic should be 3 continguous registers.

Now, my plan is to build_array_type for both "vint8mf8x2_t" and "vint8mf8x3_t" and make their TYPE_MODE is "VNx2x1SI" and "VNx3x1SI" corresponding like ARM SVE.
Then define the RTL pattern which has dest operand is a register_operand with mode  "VNx2x1SI" and "VNx3x1SI". Then we can do the codegen.

If we don't have a mode for "vint8mf8x2_t" and "vint8mf8x3_t", I don't known how to define such instruction RTL pattern. Should its dest operand mode be BLKmode?
But we want the dest operand is a register operand.



juzhe.zhong@rivai.ai
 
From: Jakub Jelinek
Date: 2023-04-11 17:16
To: juzhe.zhong
CC: Jeff Law; gcc-patches; kito.cheng; palmer; richard.sandiford; rguenther
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit
On Mon, Apr 10, 2023 at 11:14:46PM +0800, juzhe.zhong@rivai.ai wrote:
> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t
> As far as I known, they don't have tuple type for partial vector.
> However, for RVV not only has vint8m1_t, vint8m1x2_t, vint8m1x3_t, 
> vint8m1x4_t, vint8m1x5_t, vint8m1x6_t, vint8m1x7_t, vint8m1x8_t
> 
> But also, we have vint8mf8_t, vint8mf8x2_t, vint8mf8x3_t, 
> vint8mf8x4_t, vint8mf8x5_t, vint8mf8x6_t, vint8mf8x7_t, vint8mf8x8_t
> 
> vint8mf4_t, vint8mf4x2_t, vint8mf4x3_t, 
> vint8mf4x4_t, vint8mf4x5_t, vint8mf4x6_t, vint8mf4x7_t, vint8mf4x8_t
> 
> ....etc
> 
> So many tuple types.
 
Do all of them need their own mode?  I mean, can't you instead use say some
backend aggregate types which act like homogenous aggregates in various
backends?
Modes are needed for something that can appear in instructions, for
something that can be lowered say during expansion at latest you don't
need special modes.  I admit I don't know much about RVV, but if those
tuples are to be handled as configure the CPU for certain vector length,
perform some instruction on effectively variable length vector with certain
element and then reconfigure the CPU again for something else, couldn't
the only vector modes there be the variable length ones?
 
Jakub