Improve segment load/store interface with tuple types

[eopXD]

This resolves #139. This change is motivated by constant unpleasant user feedback of the current segment load/store intrinsics and hope to align the interface of segment load/store intrinsics with the non-segment ones.

This PR adds the tuple-type segment load-store intrinsics and removes the existing ones. To company the tuple-types, additional vget and vset intrinsics for them are added.

Take vlseg2e8 for example, these are the intrinsics added:

vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2(const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_m(vbool64_t mask, const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_tu(vint8mf8x2_t maskedoff_tuple, const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_tum(vbool64_t mask, vint8mf8x2_t maskedoff_tuple, const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_mu(vbool64_t mask, vint8mf8x2_t maskedoff_tuple, const int8_t *base, size_t vl);

void __riscv_vsseg2e8_v_i8mf8x2 (int8_t *base, vint8mf8x2_t v_tuple, size_t vl);
void __riscv_vsseg2e8_v_i8mf8x2_m (vbool64_t mask, int8_t *base, vint8mf8x2_t v_tuple, size_t vl);

vint8mf8_t __riscv_vget_v_i8mf8x2_i8mf8(vint8mf8x2_t src, size_t index);
vint8mf8x2_t __riscv_vset_v_i8mf8_i8mf8x(vint8mf8x2_t dest, size_t index, vint8mf8_t val);

The LLVM implementation has a proof-of-concept available:

• D146872 [1/N][IR] Permit load/store/alloca for struct of the same scalable vector type
• D146873 [2/N][POC][Clang][RISCV] Define RVV tuple types
• D147731 [3/11][POC][Clang][RISCV] Add typedef of the tuple type and define tuple type variant of vlseg2e32
• D147774 [4/11][POC][Clang][RISCV] Define tuple type variant of vsseg2e32
• D147911 [5/11][POC][Clang][RISCV] Define tuple type variant of vlseg2e32ff
• D147912 [6/11][POC][Clang][RISCV] Define tuple type variant of vlsseg2e32
• D147913 [7/11][POC][Clang][RISCV] Define tuple type variant of vssseg2e32
• D147914 [8/11][POC][Clang][RISCV] Define tuple type variant of vloxseg2ei32 vluxseg2ei32
• D147915 [9/11][POC][Clang][RISCV] Define tuple type variant of vsoxseg2ei32 vsuxseg2ei32
• D147916 [10/11][POC][Clang][RISCV] Define vget for tuple type
• D147917 [11/11][POC][Clang][RISCV] Define vset for tuple type

[lhtin]

@eopXD Maybe the return value with tuple type should directly return instead of using an argument to receive. It no need.

void __riscv_vlseg2e8_v_i8mf8(vint8mf8x2_t *v_tuple, const int8_t *base, size_t vl);

change to:

vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8(const int8_t *base, size_t vl);

[nick-knight]

I don't see the tuple types defined anywhere, although there are 300k LoC added in this PR and I may have skimmed over them. IIRC, they were removed a while back, perhaps here.

From an API perspective, I agree with other reviewers, suggesting that these loads return the tuple by value, to match other loads. My assumption is that these functions ("intrinsics") can be inlined by the compiler, so the ABI calling convention does not constrain register allocation in any way. (This assumption is supported by my experience with LLVM's implementation of these intrinsics.)

[zhongjuzhe]

Thanks for the PR that we can have tuple type finally.
Turns out GCC 13 release is comming that we can't have segment loads/stores in GCC 13.
I am gonna support them in GCC 14.
Can you tell me whether the next PR of the document is rounding mode version of fixed-point/floating-point intrinsics?

Thanks.

[eric-xtang1008]

Should the name of vget/vset intrinsics be changed according to the tuple-type?

vint8mf8_t __riscv_vget_v_u64m8_u64m4(vint8mf8x2_t src, size_t index);

changed like this:

vint8mf8_t __riscv_vget_v_i8mf8x2_i8mf8(vint8mf8x2_t src, size_t index);

[eopXD]

Thanks for all the comment above. The latest force-push includes the following change:

• Updated prototype for segment load/store to be aligned with non-segment load/store, thanks comment from @lhtin @nick-knight @kito-cheng @Incarnation-p-lee @dodohack
• Updated vget/vset function name, thanks comment from @eric-xtang1008
• Added a section under rvv-intrinsics-api.md to describe the tuple types defined and used in this PR. 9952f95

[Incarnation-p-lee]

Cool, @eopXD, Thanks for making this happen!

[Incarnation-p-lee]

LGTM, thanks @eopXD !

[zhongjuzhe]

Hi, I found there is an issue with the naming of vset intrinsic:
vint8mf8x2_t _riscv_vset_vi8mf8x2_i8mf8(vint8mf8x2_t dest, size_t index, vint8mf8_t val);

For normal LMUL > 1:
_riscv_vset_vf32m1_f32m2(dest, 0, val);

I think the tuple vset naming should be changed into:
vint8mf8x2_t _riscv_vset_vi8mf8_i8mf8x2(vint8mf8x2_t dest, size_t index, vint8mf8_t val);

[kito-cheng]

I would like segment load/store have consistent naming rule for the return value part :

vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2(const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_m(vbool64_t mask, const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_tu(vint8mf8x2_t maskedoff_tuple, const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_tum(vbool64_t mask, vint8mf8x2_t maskedoff_tuple, const int8_t *base, size_t vl);
vint8mf8x2_t __riscv_vlseg2e8_v_i8mf8x2_mu(vbool64_t mask, vint8mf8x2_t maskedoff_tuple, const int8_t *base, size_t vl);

void __riscv_vsseg2e8_v_i8mf8x2 (int8_t *base, vint8mf8x2_t v_tuple, size_t vl);
void __riscv_vsseg2e8_v_i8mf8x2_m (vbool64_t mask, int8_t *base, vint8mf8x2_t v_tuple, size_t vl);

[Incarnation-p-lee]

Just notice it may generate some test functions like this (take vsoxseg7ei64.c as an example), not sure if there is something missing or not.

void test_vsoxseg7ei64_v_f64m1(float64_t *base, vuint64m1_t bindex, vfloat64m1x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_f64m1(base, bindex, v_tuple, vl);
}

void test_vsoxseg7ei64_v_i8mf8(int8_t *base, vuint64m1_t bindex, vint8mf8x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_i8mf8(base, bindex, v_tuple, vl);
}

void test_vsoxseg7ei64_v_i8mf4(int8_t *base, vuint64m2_t bindex, vint8mf4x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_i8mf4(base, bindex, v_tuple, vl);
}

[eopXD]

Just notice it may generate some test functions like this (take vsoxseg7ei64.c as an example), not sure if there is something missing or not.

void test_vsoxseg7ei64_v_f64m1(float64_t *base, vuint64m1_t bindex, vfloat64m1x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_f64m1(base, bindex, v_tuple, vl);
}

void test_vsoxseg7ei64_v_i8mf8(int8_t *base, vuint64m1_t bindex, vint8mf8x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_i8mf8(base, bindex, v_tuple, vl);
}

void test_vsoxseg7ei64_v_i8mf4(int8_t *base, vuint64m2_t bindex, vint8mf4x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_i8mf4(base, bindex, v_tuple, vl);
}

The interface looks as intended. May you explain more, thank you.

[Incarnation-p-lee]

Just notice it may generate some test functions like this (take vsoxseg7ei64.c as an example), not sure if there is something missing or not.

void test_vsoxseg7ei64_v_f64m1(float64_t *base, vuint64m1_t bindex, vfloat64m1x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_f64m1(base, bindex, v_tuple, vl);
}

void test_vsoxseg7ei64_v_i8mf8(int8_t *base, vuint64m1_t bindex, vint8mf8x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_i8mf8(base, bindex, v_tuple, vl);
}

void test_vsoxseg7ei64_v_i8mf4(int8_t *base, vuint64m2_t bindex, vint8mf4x7_t v_tuple, size_t vl) {
  return __riscv_vsoxseg7ei64_v_i8mf4(base, bindex, v_tuple, vl);
}

The interface looks as intended. May you explain more, thank you.

Sorry for misleading you, I mean the test function was declared as void, but the body try to return something. I am not sure if it is expected or not.

[eopXD]

The interface looks as intended. May you explain more, thank you.

Sorry for misleading you, I mean the test function was declared as void, but the body try to return something. I am not sure if it is expected or not.

It is legal and should be fine, the store functions have a return type of void ;)

[Incarnation-p-lee]

The interface looks as intended. May you explain more, thank you.

Sorry for misleading you, I mean the test function was declared as void, but the body try to return something. I am not sure if it is expected or not.

It is legal and should be fine, the store functions have a return type of void ;)

Oh, I see, you would like to test the return type is void for the store intrinsic. That makes sense to me, thanks for the explanation.

[eopXD]

Change:

• Fixed vset function name as @zhongjuzhe pointed out.
• Fixed segment load/store function name for the missing trailing x{NF} as @kito-cheng pointed out.

[Incarnation-p-lee]

Just FYI that GCC upstream has supported the segment-related load/store already. Thanks @zhongjuzhe and @kito-cheng for making it happen.