[llvm] [DirectX][NFC] Leverage LLVM and DirectX intrinsic description in DXIL Op records (PR #83193)

S. Bharadwaj Yadavalli via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 28 11:34:51 PST 2024


================
@@ -102,50 +91,67 @@ static ParameterKind lookupParameterKind(StringRef typeNameStr) {
   return paramKind;
 }
 
+/// Construct an object using the DXIL Operation records specified
+/// in DXIL.td. This serves as the single source of reference for
+/// C++ code generated by this TableGen backend.
 DXILOperationDesc::DXILOperationDesc(const Record *R) {
-  OpName = R->getValueAsString("OpName");
+  OpName = R->getNameInitAsString();
   OpCode = R->getValueAsInt("OpCode");
-  OpClass = R->getValueAsDef("OpClass")->getValueAsString("Name");
-  Category = R->getValueAsDef("OpCategory")->getValueAsString("Name");
 
-  if (R->getValue("llvm_intrinsic")) {
-    auto *IntrinsicDef = R->getValueAsDef("llvm_intrinsic");
+  Doc = R->getValueAsString("Doc");
+
+  if (R->getValue("LLVMIntrinsic")) {
+    auto *IntrinsicDef = R->getValueAsDef("LLVMIntrinsic");
     auto DefName = IntrinsicDef->getName();
     assert(DefName.starts_with("int_") && "invalid intrinsic name");
     // Remove the int_ from intrinsic name.
     Intrinsic = DefName.substr(4);
+    // NOTE: It is expected that return type and parameter types of
+    // DXIL Operation are the same as that of the intrinsic. Deviations
+    // are expected to be encoded in TableGen record specification and
+    // handled accordingly here. Support to be added later, as needed.
+    // Get parameter type list of the intrinsic. Types attribute contains
+    // the list of as [returnType, param1Type,, param2Type, ...]
+    auto TypeList = IntrinsicDef->getValueAsListInit("Types");
+    unsigned TypeListSize = TypeList->size();
+    OverloadParamIndex = -1;
+    // Populate return type and parameter type names
+    for (unsigned i = 0; i < TypeListSize; i++) {
+      OpTypeNames.emplace_back(TypeList->getElement(i)->getAsString());
+      // Get the overload parameter index.
+      // REVISIT : Seems hacky. Is it possible that more than one parameter can
+      // be of overload kind?? REVISIT-2: Check for any additional constraints
+      // specified for DXIL operation restricting return type.
+      if (i > 0) {
+        auto &CurParam = OpTypeNames.back();
+        if (lookupParameterKind(CurParam) >= ParameterKind::OVERLOAD) {
+          OverloadParamIndex = i;
+        }
+      }
+    }
+    // Determine the operation class (unary/binary) based on the number of
+    // parameters As parameter types are being considered, skip return type
+    auto ParamSize = TypeListSize - 1;
+    if (ParamSize == 0) {
+      OpClass = "Nullary";
+    } else if (ParamSize == 1) {
+      OpClass = "Unary";
+    } else if (ParamSize == 2) {
+      OpClass = "Binary";
+    } else {
+      // TODO: Extend as needed
+      llvm_unreachable("Unhandled parameter size");
+    }
+    // NOTE: For now, assume that attributes of DXIL Operation are the same as
+    // that of the intrinsic. Deviations are expected to be encoded in TableGen
+    // record specification and handled accordingly here. Support to be added
+    // later.
----------------
bharadwajy wrote:

Done.

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


More information about the llvm-commits mailing list