[clang] [CIR] floating-point, pointer, and function types (PR #120484)

[David Olsen via cfe-commits]

================
@@ -129,4 +130,224 @@ def PrimitiveInt
     : AnyTypeOf<[UInt8, UInt16, UInt32, UInt64, SInt8, SInt16, SInt32, SInt64],
                 "primitive int", "::cir::IntType">;
 
+//===----------------------------------------------------------------------===//
+// FloatType
+//===----------------------------------------------------------------------===//
+
+class CIR_FloatType<string name, string mnemonic>
+    : CIR_Type<name, mnemonic,
+          [
+            DeclareTypeInterfaceMethods<DataLayoutTypeInterface>,
+            DeclareTypeInterfaceMethods<CIRFPTypeInterface>,
+          ]> {}
+
+def CIR_Single : CIR_FloatType<"Single", "float"> {
+  let summary = "CIR single-precision 32-bit float type";
+  let description = [{
+    A 32-bit floating-point type whose format is IEEE-754 `binary32`.  It
+    represents the types `float`, `_Float32`, and `std::float32_t` in C and C++.
+  }];
+}
+
+def CIR_Double : CIR_FloatType<"Double", "double"> {
+  let summary = "CIR double-precision 64-bit float type";
+  let description = [{
+    A 64-bit floating-point type whose format is IEEE-754 `binary64`. It
+    represents the types `double', '_Float64`, `std::float64_t`, and `_Float32x`
+    in C and C++.  This is the underlying type for `long double` on some
+    platforms, including Windows.
+  }];
+}
+
+def CIR_FP16 : CIR_FloatType<"FP16", "f16"> {
+  let summary = "CIR half-precision 16-bit float type";
+  let description = [{
+    A 16-bit floating-point type whose format is IEEE-754 `binary16`. It
+    represents the types '_Float16` and `std::float16_t` in C and C++.
+  }];
+}
+
+def CIR_BFloat16 : CIR_FloatType<"BF16", "bf16"> {
+  let summary = "CIR bfloat16 16-bit float type";
+  let description = [{
+    A 16-bit floating-point type in the bfloat16 format, which is the same as
+    IEEE `binary32` except that the lower 16 bits of the mantissa are missing.
+    It represents the type `std::bfloat16_t` in C++, also spelled `__bf16` in
+    some implementations.
+  }];
+}
+
+def CIR_FP80 : CIR_FloatType<"FP80", "f80"> {
+  let summary = "CIR x87 80-bit float type";
+  let description = [{
+    An 80-bit floating-point type in the x87 extended precision format.  The
+    size and alignment of the type are both 128 bits, even though only 80 of
+    those bits are used.  This is the underlying type for `long double` on Linux
+    x86 platforms, and it is available as an extension in some implementations.
+  }];
+}
+
+def CIR_FP128 : CIR_FloatType<"FP128", "f128"> {
+  let summary = "CIR quad-precision 128-bit float type";
+  let description = [{
+    A 128-bit floating-point type whose format is IEEE-754 `binary128`. It
+    represents the types `_Float128` and `std::float128_t` in C and C++, and the
+    extension `__float128` in some implementations.  This is the underlying type
+    for `long double` on some platforms including Linux Arm.
+  }];
+}
+
+def CIR_LongDouble : CIR_FloatType<"LongDouble", "long_double"> {
+  let summary = "CIR float type for `long double`";
+  let description = [{
+    A floating-point type that represents the `long double` type in C and C++.
+
+    The underlying floating-point format of a `long double` value depends on the
+    target platform and the implementation. The `underlying` parameter specifies
----------------
dkolsen-pgi wrote:

Good idea.  But I'm not sure where in the setup code to put such a check, since I need to check the format of the Clang types `float` and `double` and I'm not sure how best to access them in the ClangIR setup code.  Instead I have added `assert`s to the `BuiltinType::Float` and `BuiltinType::Double` cases in `CIRGenTypes::convertType`.  The `assert` will fire if the source code tries to use `float` or `double` on a platform where they aren't IEEE 32-bit and 64-bit.  The type `long double` already has a similar check in `CIRGenBuilderTy::getLongDoubleTy`.  I believe all the other non-standard floating-point types have fixed formats that shouldn't depend on the target, so they don't need similar checks.

https://github.com/llvm/llvm-project/pull/120484