[llvm] [DirectX][NFC] Refine DXIL Type abstraction framework in DXIL.td (PR #81692)

[Chris B via llvm-commits]

================
@@ -35,30 +35,78 @@ def BinaryUintCategory : DXILOpCategory<"Binary uint">;
 def UnaryFloatCategory : DXILOpCategory<"Unary float">;
 def ComputeIDCategory : DXILOpCategory<"Compute/Mesh/Amplification shader">;
 
-// Following are the scalar types supported by DXIL operations and are synonymous
-// to llvm_*_ty defined for readability and ease of use in the context of this file.
+// Abstraction of DXIL Data Type Categories
+class DXILTypeCategory<string categoryStr> {
+  string Name = categoryStr;
+}
+
+// Concrete DXIL Data Type Categories that are supported
+foreach cat = ["Scalar", "Vector", "Matrix",
+               "Sampler", "Texture", "Buffer",
+               "Struct", "UserDefined", "Array", "StateObject"] in {
+  def cat : DXILTypeCategory<cat>;
+}
+
+// Pseudo DXIL Type category to represent data characteristics not supported
+// as DXIL types.
+def PseudoCategory : DXILTypeCategory<"PseudoCategory">;
+
+// Abstraction of DXIL Types
+class DXILType<DXILTypeCategory category, string name> {
+    DXILTypeCategory Category = category;
+    string Name = name;
+}
+
+// Supported DXIL Type categories
+class DXILScalarType<string typeNameString> : DXILType<Scalar, typeNameString>;
+class DXILVectorType<string typeNameString> : DXILType<Vector, typeNameString>;
+class DXILMatrixType<string typeNameString> : DXILType<Matrix, typeNameString>;
+class DXILSamplerType<string typeNameString> : DXILType<Sampler, typeNameString>;
+class DXILTextureType<string typeNameString> : DXILType<Texture, typeNameString>;
+class DXILBufferType<string typeNameString> : DXILType<Buffer, typeNameString>;
+class DXILStructType<string typeNameString> : DXILType<Struct, typeNameString>;
+class DXILUserDefinedType<string typeNameString> : DXILType<UserDefined, typeNameString>;
+class DXILArrayType<string typeNameString> : DXILType<Array, typeNameString>;
+class DXILStateObjectType<string typeNameString> : DXILType<StateObject, typeNameString>;
 
-def voidTy  : LLVMType<isVoid>;
+// Concrete Pseudo Types
+
+// Overload - used to convey overload specification of DXIL operation parameters.
+def OverloadTy : DXILType<PseudoCategory, "overload">;
+
+// Handle - used to represent handle (i8*) type
+def HandleTy   : DXILType<PseudoCategory, "handle">;
+
+//  Resource - used to represent a resource
+def ResourceTy : DXILType<PseudoCategory, "resource">;
+
+// Concrete scalar types supported by DXIL operations.
+def VoidTy  : DXILScalarType<"void">;
 
 // Floating point types
-def f16Ty   : LLVMType<f16>;
-def f32Ty   : LLVMType<f32>;
-def f64Ty   : LLVMType<f64>;
+def Float16Ty   : DXILScalarType<"f16">;
+def Float32Ty   : DXILScalarType<"f32">;
+def Float64Ty   : DXILScalarType<"f64">;
 
 // Integer types
-def i1Ty   : LLVMType<i1>;
-def i8Ty   : LLVMType<i8>;
-def i16Ty  : LLVMType<i16>;
-def i32Ty  : LLVMType<i32>;
-def i64Ty  : LLVMType<i64>;
+def Int1Ty   : DXILScalarType<"i1">;
----------------
llvm-beanz wrote:

I'm not sure I understand why we're making this change. DXIL types are a subset of LLVM IR types. My initial reaction to seeing this is that we're making our types different... but why?

I'm also unsure why we're not just using the type definitions from Intrinsics.td since we include it above.



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