[RISCV] Add type aliases float16_t, float32_t and float64_t

[wangpc]

Summary

We use them in RVV intrinsics doc but there is no definition
in riscv_vector.h, which is confusing for users. This matches
what GCC does too.

There are too many tests using the raw types, so we keep them
untouched.

[asb]

Thanks for the patch - can you add test coverage for this please?

[• pcwang-thead]

Add a test to check RVV type aliases.

[• pcwang-thead]

Besides, should we add vread_csr and vwrite_csr like what in GCC?
These two functions don't exist in RVV intrinsics doc Found it! Read/Write URW vector CSRs, is it a historical problem?

[• pcwang-thead]

Move to separate RVVHeader.

[khchen]

I think we have no consensus in https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/18#issuecomment-817890161, and most people disagree the current naming,
maybe we need to have more followup discussion before landing this patch.

For example, maybe _Float16 should be supported when enable zvh, not zvfh?

[• pcwang-thead]

In D125765#3524456, @khchen wrote:

I think we have no consensus in https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/18#issuecomment-817890161, and most people disagree the current naming,
maybe we need to have more followup discussion before landing this patch.

Thanks for your reminding of previous discussion!
Should we put this in next sync-up discussion agenda and settle it down? There are already some large code bases based GCC implementation, we should make it stable before it becomes too hard to change.

For example, maybe _Float16 should be supported when enable zvh, not zvfh?

You mean zfh? float16_t is only used in RVV intrinsics, so I think it is OK to me. And it is the same as generated type aliases in riscv_vector.h(at about line 130):

#if defined(__riscv_zvfh)
typedef __rvv_float16mf4_t vfloat16mf4_t;
typedef __rvv_float16mf2_t vfloat16mf2_t;
typedef __rvv_float16m1_t vfloat16m1_t;
typedef __rvv_float16m2_t vfloat16m2_t;
typedef __rvv_float16m4_t vfloat16m4_t;
typedef __rvv_float16m8_t vfloat16m8_t;
#endif

[khchen]

In D125765#3526835, @pcwang-thead wrote:

In D125765#3524456, @khchen wrote:

I think we have no consensus in https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/18#issuecomment-817890161, and most people disagree the current naming,
maybe we need to have more followup discussion before landing this patch.

Thanks for your reminding of previous discussion!
Should we put this in next sync-up discussion agenda and settle it down? There are already some large code bases based GCC implementation, we should make it stable before it becomes too hard to change.

I think so. But I think maybe we need to raise an issue somewhere (maybe riscv-c-api-doc) to gather opinions from community first. (see below)

For example, maybe _Float16 should be supported when enable zvh, not zvfh?

You mean zfh? float16_t is only used in RVV intrinsics, so I think it is OK to me. And it is the same as generated type aliases in riscv_vector.h(at about line 130):

Yes, sorry for my typo.

I think maybe we need to have more comprehensive consideration about define floating type aliases in RISC-V world.
For example, before RISC-V support half floating type, we had posted https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/172 to update the spec for half floating-point type.

or like https://github.com/riscv-non-isa/riscv-c-api-doc/pull/25, it's trying to define a unified naming rules for all intrinsics.
so I think maybe we also need to have RFC in riscv-c-api-doc to define the convention for floating type aliases.

#if defined(__riscv_zvfh)
typedef __rvv_float16mf4_t vfloat16mf4_t;
typedef __rvv_float16mf2_t vfloat16mf2_t;
typedef __rvv_float16m1_t vfloat16m1_t;
typedef __rvv_float16m2_t vfloat16m2_t;
typedef __rvv_float16m4_t vfloat16m4_t;
typedef __rvv_float16m8_t vfloat16m8_t;
#endif

[asb]

Adding eop as a reviewer.

[eopXD]

Sorry for the late reply, I missed this in may mails.

I see that the motivation start from where you spotted this type alias. However it was essentially just an act for convenience so we don't have to map a more irregular pattern of ( _Float16, float, double) when generating the test cases by code. Is it necessary that we have them in the header? On the other hand, these are scalar floating-point types, and if we want them to be defined, I agree with Zakk that starting a discussion in riscv-c-api will be helpful.

[wangpc]

I don't have any thoughts on this patch now.

In D125765#4511637, @eopXD wrote:

Sorry for the late reply, I missed this in may mails.

I see that the motivation start from where you spotted this type alias. However it was essentially just an act for convenience so we don't have to map a more irregular pattern of ( _Float16, float, double) when generating the test cases by code. Is it necessary that we have them in the header? On the other hand, these are scalar floating-point types, and if we want them to be defined, I agree with Zakk that starting a discussion in riscv-c-api will be helpful.

Yeah, I agree. But I won't continue this now.

clang/include/clang/Basic/riscv_vector.td

let Name = NAME,
       }
       }] in {
         foreach s_p = suffixes_prototypes in {
           def : RVVBuiltin<s_p[0], s_p[1], type_range>;
         }
   }
 }
 
+// Define type aliases float16_t, float32_t and float64_t, they are used in
+// RVV intrinsics doc.
+let HeaderCode =
+[{
+#if defined(__riscv_zvfh)
+typedef _Float16 float16_t;
+#endif
+#if defined(__riscv_f)
+typedef float float32_t;
+#endif
+#if defined(__riscv_d)
+typedef double float64_t;
+#endif
+}] in
+def float_type_aliases: RVVHeader;
+
 // 6. Configuration-Setting Instructions
 // 6.1. vsetvli/vsetvl instructions
 
 // vsetvl/vsetvlmax are a macro because they require constant integers in SEW
 // and LMUL.
 let HeaderCode =
 [{
 #define vsetvl_e8mf8(avl) __builtin_rvv_vsetvli((size_t)(avl), 0, 5)

clang/test/CodeGen/RISCV/rvv-type-aliases.c

+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d -target-feature +v \
+// RUN:     -target-feature +zfh -target-feature +experimental-zvfh \
+// RUN:     -fsyntax-only -verify -ast-dump %s | FileCheck %s
+
+#include <riscv_vector.h>
+
+// expected-no-diagnostics
+void bar(void) {
+  // CHECK: f16 'float16_t':'_Float16'
+  float16_t f16;
+  // CHECK: f32 'float32_t':'float'
+  float32_t f32;
+  // CHECK: f64 'float64_t':'double'
+  float64_t f64;
+
+  // CHECK: b1 'vbool1_t':'__rvv_bool1_t'
+  vbool1_t b1;
+  // CHECK: b2 'vbool2_t':'__rvv_bool2_t'
+  vbool2_t b2;
+  // CHECK: b4 'vbool4_t':'__rvv_bool4_t'
+  vbool4_t b4;
+  // CHECK: b8 'vbool8_t':'__rvv_bool8_t'
+  vbool8_t b8;
+  // CHECK: b16 'vbool16_t':'__rvv_bool16_t'
+  vbool16_t b16;
+  // CHECK: b32 'vbool32_t':'__rvv_bool32_t'
+  vbool32_t b32;
+  // CHECK: b64 'vbool64_t':'__rvv_bool64_t'
+  vbool64_t b64;
+
+  // CHECK: i8mf8 'vint8mf8_t':'__rvv_int8mf8_t'
+  vint8mf8_t i8mf8;
+  // CHECK: u8mf8 'vuint8mf8_t':'__rvv_uint8mf8_t'
+  vuint8mf8_t u8mf8;
+  // CHECK: i8mf4 'vint8mf4_t':'__rvv_int8mf4_t'
+  vint8mf4_t i8mf4;
+  // CHECK: u8mf4 'vuint8mf4_t':'__rvv_uint8mf4_t'
+  vuint8mf4_t u8mf4;
+  // CHECK: i8mf2 'vint8mf2_t':'__rvv_int8mf2_t'
+  vint8mf2_t i8mf2;
+  // CHECK: u8mf2 'vuint8mf2_t':'__rvv_uint8mf2_t'
+  vuint8mf2_t u8mf2;
+  // CHECK: i8m1 'vint8m1_t':'__rvv_int8m1_t'
+  vint8m1_t i8m1;
+  // CHECK: u8m1 'vuint8m1_t':'__rvv_uint8m1_t'
+  vuint8m1_t u8m1;
+  // CHECK: i8m2 'vint8m2_t':'__rvv_int8m2_t'
+  vint8m2_t i8m2;
+  // CHECK: u8m2 'vuint8m2_t':'__rvv_uint8m2_t'
+  vuint8m2_t u8m2;
+  // CHECK: i8m4 'vint8m4_t':'__rvv_int8m4_t'
+  vint8m4_t i8m4;
+  // CHECK: u8m4 'vuint8m4_t':'__rvv_uint8m4_t'
+  vuint8m4_t u8m4;
+  // CHECK: i8m8 'vint8m8_t':'__rvv_int8m8_t'
+  vint8m8_t i8m8;
+  // CHECK: u8m8 'vuint8m8_t':'__rvv_uint8m8_t'
+  vuint8m8_t u8m8;
+
+  // CHECK: i16mf4 'vint16mf4_t':'__rvv_int16mf4_t'
+  vint16mf4_t i16mf4;
+  // CHECK: u16mf4 'vuint16mf4_t':'__rvv_uint16mf4_t'
+  vuint16mf4_t u16mf4;
+  // CHECK: i16mf2 'vint16mf2_t':'__rvv_int16mf2_t'
+  vint16mf2_t i16mf2;
+  // CHECK: u16mf2 'vuint16mf2_t':'__rvv_uint16mf2_t'
+  vuint16mf2_t u16mf2;
+  // CHECK: i16m1 'vint16m1_t':'__rvv_int16m1_t'
+  vint16m1_t i16m1;
+  // CHECK: u16m1 'vuint16m1_t':'__rvv_uint16m1_t'
+  vuint16m1_t u16m1;
+  // CHECK: i16m2 'vint16m2_t':'__rvv_int16m2_t'
+  vint16m2_t i16m2;
+  // CHECK: u16m2 'vuint16m2_t':'__rvv_uint16m2_t'
+  vuint16m2_t u16m2;
+  // CHECK: i16m4 'vint16m4_t':'__rvv_int16m4_t'
+  vint16m4_t i16m4;
+  // CHECK: u16m4 'vuint16m4_t':'__rvv_uint16m4_t'
+  vuint16m4_t u16m4;
+  // CHECK: i16m8 'vint16m8_t':'__rvv_int16m8_t'
+  vint16m8_t i16m8;
+  // CHECK: u16m8 'vuint16m8_t':'__rvv_uint16m8_t'
+  vuint16m8_t u16m8;
+
+  // CHECK: i32mf2 'vint32mf2_t':'__rvv_int32mf2_t'
+  vint32mf2_t i32mf2;
+  // CHECK: u32mf2 'vuint32mf2_t':'__rvv_uint32mf2_t'
+  vuint32mf2_t u32mf2;
+  // CHECK: i32m1 'vint32m1_t':'__rvv_int32m1_t'
+  vint32m1_t i32m1;
+  // CHECK: u32m1 'vuint32m1_t':'__rvv_uint32m1_t'
+  vuint32m1_t u32m1;
+  // CHECK: i32m2 'vint32m2_t':'__rvv_int32m2_t'
+  vint32m2_t i32m2;
+  // CHECK: u32m2 'vuint32m2_t':'__rvv_uint32m2_t'
+  vuint32m2_t u32m2;
+  // CHECK: i32m4 'vint32m4_t':'__rvv_int32m4_t'
+  vint32m4_t i32m4;
+  // CHECK: u32m4 'vuint32m4_t':'__rvv_uint32m4_t'
+  vuint32m4_t u32m4;
+  // CHECK: i32m8 'vint32m8_t':'__rvv_int32m8_t'
+  vint32m8_t i32m8;
+  // CHECK: u32m8 'vuint32m8_t':'__rvv_uint32m8_t'
+  vuint32m8_t u32m8;
+
+  // CHECK: i64m1 'vint64m1_t':'__rvv_int64m1_t'
+  vint64m1_t i64m1;
+  // CHECK: u64m1 'vuint64m1_t':'__rvv_uint64m1_t'
+  vuint64m1_t u64m1;
+  // CHECK: i64m2 'vint64m2_t':'__rvv_int64m2_t'
+  vint64m2_t i64m2;
+  // CHECK: u64m2 'vuint64m2_t':'__rvv_uint64m2_t'
+  vuint64m2_t u64m2;
+  // CHECK: i64m4 'vint64m4_t':'__rvv_int64m4_t'
+  vint64m4_t i64m4;
+  // CHECK: u64m4 'vuint64m4_t':'__rvv_uint64m4_t'
+  vuint64m4_t u64m4;
+  // CHECK: i64m8 'vint64m8_t':'__rvv_int64m8_t'
+  vint64m8_t i64m8;
+  // CHECK: u64m8 'vuint64m8_t':'__rvv_uint64m8_t'
+  vuint64m8_t u64m8;
+
+  // CHECK: f16mf4 'vfloat16mf4_t':'__rvv_float16mf4_t'
+  vfloat16mf4_t f16mf4;
+  // CHECK: f16mf2 'vfloat16mf2_t':'__rvv_float16mf2_t'
+  vfloat16mf2_t f16mf2;
+  // CHECK: f16m1 'vfloat16m1_t':'__rvv_float16m1_t'
+  vfloat16m1_t f16m1;
+  // CHECK: f16m2 'vfloat16m2_t':'__rvv_float16m2_t'
+  vfloat16m2_t f16m2;
+  // CHECK: f16m4 'vfloat16m4_t':'__rvv_float16m4_t'
+  vfloat16m4_t f16m4;
+  // CHECK: f16m8 'vfloat16m8_t':'__rvv_float16m8_t'
+  vfloat16m8_t f16m8;
+
+  // CHECK: f32mf2 'vfloat32mf2_t':'__rvv_float32mf2_t'
+  vfloat32mf2_t f32mf2;
+  // CHECK: f32m1 'vfloat32m1_t':'__rvv_float32m1_t'
+  vfloat32m1_t f32m1;
+  // CHECK: f32m2 'vfloat32m2_t':'__rvv_float32m2_t'
+  vfloat32m2_t f32m2;
+  // CHECK: f32m4 'vfloat32m4_t':'__rvv_float32m4_t'
+  vfloat32m4_t f32m4;
+  // CHECK: f32m8 'vfloat32m8_t':'__rvv_float32m8_t'
+  vfloat32m8_t f32m8;
+
+  // CHECK: f64m1 'vfloat64m1_t':'__rvv_float64m1_t'
+  vfloat64m1_t f64m1;
+  // CHECK: f64m2 'vfloat64m2_t':'__rvv_float64m2_t'
+  vfloat64m2_t f64m2;
+  // CHECK: f64m4 'vfloat64m4_t':'__rvv_float64m4_t'
+  vfloat64m4_t f64m4;
+  // CHECK: f64m8 'vfloat64m8_t':'__rvv_float64m8_t'
+  vfloat64m8_t f64m8;
+}