craig.topper added inline comments.
================
Comment at: clang/include/clang/Basic/RISCVVTypes.def:67
+RVV_VECTOR_TYPE_INT("__rvv_int8m2_t", RvvInt8m2, RvvInt8m2Ty, 16, 8, 1,
true)
+RVV_VECTOR_TYPE_INT("__rvv_int8m4_t", RvvInt8m4, RvvInt8m4Ty, 32, 8, 1,
true)
+RVV_VECTOR_TYPE_INT("__rvv_int8m8_t", RvvInt8m8, RvvInt8m8Ty, 64, 8, 1,
true)
----------------
HsiangKai wrote:
> kito-cheng wrote:
> > khchen wrote:
> > > evandro wrote:
> > > > craig.topper wrote:
> > > > > craig.topper wrote:
> > > > > > jrtc27 wrote:
> > > > > > > liaolucy wrote:
> > > > > > > > RISC-V V has too many types, more than 200. All types use
> > > > > > > > builtin types? Is it possible to reduce the number of builtin
> > > > > > > > types?
> > > > > > > Indeed this is madness, what's wrong with just using
> > > > > > > `__attribute__((vector_size(n)))` on the right type? We should
> > > > > > > not be encouraging people to write code with
> > > > > > > architecture-specific types... but if we _really_ need these
> > > > > > > because RISC-V GCC decided this is how RISC-V V is going to look
> > > > > > > them can we not just shove them all in a header as typedef's for
> > > > > > > the architecture-independent attributed types and push that
> > > > > > > complexity out of the compiler itself?
> > > > > > We are using <vscale x 1 x i64> to specify types in IR. The size of
> > > > > > the fixed part is being used to control the LMUL parameter. There
> > > > > > is currently no way to spell a scalable vector type in C in a
> > > > > > generic way.
> > > > > >
> > > > > > Alternatively I guess we could make LMUL a parameter to the
> > > > > > intrinsic and create the scalable IR types in the frontend based on
> > > > > > it?
> > > > > I do wonder why we bothered to have signed and unsigned types. The
> > > > > signedness of the operation should be carried in the intrinsic name.
> > > > Some integer operations distinguish between signed and unsigned.
> > > > I do wonder why we bothered to have signed and unsigned types. The
> > > > signedness of the operation should be carried in the intrinsic name.
> > >
> > > I think the only good thing for supporting both signed and unsigned type
> > > is that are more readable and compiler can does type checking for
> > > programmer.
> > >
> > > maybe the alternative way is changing intrinsic naming rule like
> > >
> > > ```
> > > vint32m1_t a, b, c;
> > > a = vadd_i32m1(b, c);
> > > vuint32m1_t a, b, c;
> > > a = vadd_u32m1(b, c);
> > > vfloat32m1_t a, b, c;
> > > a = vadd_f32m1(b, c);
> > > ```
> > One quick thought about this, if the concern is too much built-in types are
> > introduced in clang, maybe we could add a new attribute like
> > `__attribute__((vector_size(n)))`, maybe named
> > `__attribute__((riscv_scaleble_vector("[1|2|4|8|f2|f4|f8]")))`? and use
> > that to define vector types like `typedef int
> > __attribute__((riscv_scaleble_vector("2"))) vintm2_t`.
> To have signed and unsigned types, we could do type checking for the
> builtins. For example, we have vmaxu_vv and vmax_vv. Users could pass signed
> vector types into unsigned version vmaxu_vv if we only have types without
> signed/unsigned. How could we tell users they pass values into the wrong
> builtins?
Maybe I've been corrupted by X86 where there is just a single 128-bit integer
vector type. Even though there are 8, 16, 32, 64 bit element operations with
some being signed/unsigned.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D92715/new/
https://reviews.llvm.org/D92715
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
