Vector tuple type #17
Comments
|
'native', pre-defined tuple simply needs to exist (for things like Zvlsseg, etc.) and have accessors so they can be (de)constructed; the ability to access/update with either struct-like or array-like syntax falls under the "good-to-have" from my point-of-view - I could live without that if it's too difficult to implement. If it's doable and you want an opinion between the options, mine is 'whichever is easier to implement' :-) (I'm guessing array). Used-defined arrays with vector element would be good for some algorithms (e.g. storing locally a copy of data for some block-based algorithms like they have in video processing). Arm might consider that for SVE - I've put a request for it and they didn't say 'no' straight away ;-) User-defined structure with vector element would be nice, but maybe too difficult to implement (alignment rules are going to be hell...) and not worth the effort. I don't think Arm will do that for SVE. In your examples, when you write |
|
@rdolbeau thanks your feedback, and yes, I am seeking feedback between those options. Honestly I didn't have idea about the implementation cost amount those options yet. So personally I am not rush to decide which approach other than first option, just collect more feedback at this stage.
The data layout of vector tuple type same as the vector type version but repeat Conceptually vint32m2x3_t is equivalent to vint32m2_t[3]. So yes, vint32m2x3_t is SLEN-dependent if LMUL > 1, and vfloat64m1x3_t is implementation-independent data layout. |
|
I think it might be slightly better to use structs instead of arrays. C and C++ don't have values of array type and as such they can't be returned from a function call. That would be the case of a load from Zvlsseg, in which a tuple of registers vfloat64m1x3_t vlseg3e_v_f64m1x3(const double *base);Arguments don't need to have structs (we could always flatten them) but for consistency I'd expect the store look like this. void vsseg3e_v_f64m1x3(const double *base, vfloat64m1x3_t);In that sense that vfloat64m1x3_t vt;
vt.v0 = ...;
... = vt.v2If we focus only on intrinsic functionality, it is unclear to me we need to allow users defining their own structs or array types with RVV vectors in them. So my stance now would be like @kito-cheng 1 (a primitive type) above plus as much behaviour of 2 that makes sense for it. In that sense I'd be inclined to do something like Arm's ACLE for SVE ( https://static.docs.arm.com/100987/0000/acle_sve_100987_0000_00_en.pdf ). Note that in general (page 13)
But then in page 14
Nothing seems to prevent making those types typedef __sizeless_struct { svfloat64_t v0, v1, v2; } svfloat64x3_t; |
This paragraph seems gone in later version, For some implementation detail for SVE GCC 10, they allow struct-style initialization, but other operation must call intrinsic function: svfloat64_t s64;
svfloat64x3_t s64x3 = {s64, s64, s64}; // Creation.
s64x3 = svcreate3(s64, s64, s64); // Creation.
s64x3 = svset3(s64x3, 1, s64); // Insertion
s64 = svget3(s64x3, 2); // Extraction |
Thanks @kito-cheng I wasn't aware of the new version.
This is a reasonable alternative to using structs. |
eopXD
added
the
Revisit after v1.0
|
@kito-cheng I test "Primitive style" way with vcreate_* |
|
sometimes need must use array vector type for easy coding so now ,what is the best solution for declaration rvv array like at the same, do not import use more instruct I build args: |
|
i test -march=rv64gcv with do not have issue, but use -march=rv64gcv0p7 have "more move instruct" issue BUT, there are so many board only support v0p7 now, so any possible fix this issue on v0p7 |
|
Closing this issue and redirecting to #139. The question essentially boils down to how do we enable sizeless struct in the compiler implementation. |
That sounds like a T-head toolchain issue rather than intrinsic interface issue, I would suggest you could report that to T-head directly. |
There is several possible to implement vector tuple type:
The advantage of 2, 3, 4 and 5 is it could provide syntax sugar to access element in the vector tuple type instead of intrinsic function call:
Currently SVE's GCC implementation is
4and disallow declare array and struct with scalable vector type.The text was updated successfully, but these errors were encountered: