[llvm] [DXIL][Doc] Update specification of to use TableGen list instead of dag (PR #99055)

[David Peixotto via llvm-commits]

================
@@ -93,76 +93,81 @@ attributes are specified as fields of the ``DXILOp`` class as described below.
         class DXILOpClass;
 
    Concrete operation records, such as ``unary`` are defined by inheriting from ``DXILOpClass``.
-6. Return and argument types of the operation are represented as ``dag``s using the
-   special markers ``out`` and ``ins``. An overload type, if supported by the operation, is
-   denoted as the positional type ``dxil_overload_ty`` in the argument or in the result, where
-   ``dxil_overload_ty`` is defined to be synonymous to ``llvm_any_ty``.
+6. Return type of the operation is represented as ``LLVMType``.
+7. Operation arguments are represented as a list of ``LLVMType`` with each type
+   corresponding to the argument position. An overload type, if supported by the operation, is
+   denoted as the positional type ``overloadTy`` in the argument or in the result, where
+   ``overloadTy`` is defined to be synonymous to ``llvm_any_ty``.
 
    .. code-block::
 
-      defvar dxil_overload_ty = llvm_any_ty
+      defvar overloadTy = llvm_any_ty
 
+   Empty list, ``[]`` represents an operation with no arguments.
 
-7. Valid overload types and shader stages predicated on Shader Model version are specified
-   as a list of ``Constraint`` records. Representation of ``Constraints`` class is described
-   a later section.
-8. Various attributes of the DXIL Operation that are not predicated on Shader Model version
-   are represented as a ``dag`` using the special marker ``attrs``. Representation of ``Attributes`` 
+8. Valid operation overload types predicated on DXIL version are specified as
+   a list of ``VersionedOverloads`` records. Representation of ``VersionedOverloads``
    class is described in a later section.
+9.  Valid shader stages predicated on DXIL version are specified as a list of
+    ``VersionedStages`` records. Representation of ``VersionedStages`` class is
+    described in a later section.
+10. Various attributes of the DXIL Operation are represented as a ``list`` of
+    ``VersionedAttributes`` class records. Representation of ``VersionedAttributes``
+    class is described in a later section.
 
-A DXIL Operation is represented by the following TableGen class by encapsulating the various
-TableGen representations of its attributes described above.
+Types specific to DXIL
+----------------------
+
+Type notation used in this document viz., ``<size>Ty`` corresponds to TableGen records for
+LLVM types ``llvm_<size>_ty``. Apart from ``overloadTy`` described above, ``resRetF32Ty`` is
+used to denote resource return type and ``handleTy`` is used to denote handle type.
+
+Specification of DXIL Operation
+================================
+
+A DXIL Operation is represented by the following TableGen class that encapsulates the various
+TableGen representations of its properties described above.
 
 .. code-block::
 
    // Abstraction DXIL Operation
-   class DXILOp {
+   class DXILOp<int opcode, DXILOpClass opclass> {
      // A short description of the operation
      string Doc = "";
 
      // Opcode of DXIL Operation
-     int OpCode = 0;
+     int OpCode = opcode;
 
      // Class of DXIL Operation.
-     DXILOpClass OpClass = UnknownOpClass;
+     DXILOpClass OpClass = opclass;
 
      // LLVM Intrinsic DXIL Operation maps to
      Intrinsic LLVMIntrinsic = ?;
 
-     // Dag containing the arguments of the op. Default to 0 arguments.
-     dag arguments = (ins);
+     // Result type of the op.
+     list<LLVMType> result = [];
----------------
dmpots wrote:

Why is the result type a list? I think we can't ever have multiple return types since these are all basically llvm function calls and those only support a single return type.

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