[llvm] [DirectX][DXIL] Update DXIL Op TableGen Specification (PR #95807)

Justin Bogner via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 19 11:08:05 PDT 2024


================
@@ -14,147 +14,254 @@ Introduction
 encapsulates, among other information, various DXIL Operations in
 `hctdb.py <https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/hct/hctdb.py>`_.
 DXIL Operations are represented in one of the following `two ways
-<https://github.com/microsoft/DirectXShaderCompiler/blob/130877392c263888ef06bab768856d3dab1f1c9a/docs/DXIL.rst#L1978>`_:
+<https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#operations>`_:
 
 #. Using LLVM instructions.
 #. Using LLVM External functions. These are represented in LLVM IR as follows:
+
    * "Standard" LLVM intrinsics (e.g., ``llvm.sin.*``) and
    * HLSL intrinsics (defined as LLVM intrinsics in ``llvm/include/llvm/IR/IntrinsicsDirectX.td``, e.g., ``llvm.dx.*``)
 
    These are  collectively referred to as `LLVM Intrinsics` in this note.
 
-Following is the complete list of properties of DXIL Ops with the corresponding field name
-as used in ``hctdb.py``. A DXIL Op is represented by a set of associated properties. These
-are categorized into two groups - viz., those that are (1) consumed in DXIL backend passes
-and (2) consumed in other usage scenarios such as validation, DXIL reader, etc.
+Following is the complete list of attributes of DXIL Ops with the corresponding field name
+as used in ``hctdb.py``. A DXIL Op is represented by a set of associated attributes. These
+are consumed in DXIL backend passes as well as in other usage scenarios such as validation, 
+DXIL reader, etc.
 
-A. Properties consumed in DXIL backend passes
+A. Attributes consumed in DXIL backend passes
 
    1. Name of operation (``dxil_op``)
-   2. The generic or HLSL-specific intrinsic that maps to the operation (``llvm_name``).
-   3. Unique Integer ID (``dxil_opid``)
-   4. Operation Class signifying the name and function signature of the operation (``dxil_class``).
-      This string is an integral part of the DXIL Op function name and is constructed in
-      the format ``dx.op.<class-name>.<overload-type>``. The DXIL validator checks for any
-      deviation from this for each of the DXIL Op call.
-   5. List of valid overload types for the operation (``oload_types``).
-   6. Required DXIL Version with support for the operation.
-   7. A string that documents the operation (``doc``) - This is not strictly necessary but is included
+   2. A string that documents the operation (``doc``) - This is not strictly necessary but is included
       for readability and documentation of the operation.
-
-B. Properties consumed in other usage scenarios
-
-   1. Required minimum Shader Model (``shader_model``).
-   2. Minimum shader model required with translation by linker (``shader_model_translated``)
-   3.  List of shader stages applicable to (``shader_stages``), empty for all.
-   4.  Memory access attributes of the operation (``fn_attr``).
-   5.  Boolean attributes of operation to indicate if it
-
-       * is some kind of a derivative (``is_derivative``)
-       * requires gradient calculation (``is_gradient``)
-       * is a sampler feedback (``is_feedback``)
-       * requires in-wave, cross-lane functionality (``is_wave``)
-       * requires that all of its inputs are uniform across the wave (``requires_uniform_inputs``).
-       * is a barrier operation (``is_barrier``).
+   3. The generic or HLSL-specific intrinsic that maps to the operation (``llvm_name``).
+   4. Unique Integer ID (``dxil_opid``)
+   5. Operation Class signifying the name and function signature of the operation (``dxil_class``).
+      This string is an integral part of the DXIL Op function name and is constructed in
+      the format ``dx.op.<class-name>.<overload-type>``. Each DXIL Op call target function name 
+      is required to conform to this format per existing contract with the driver.
+   6. List of valid overload types for the operation (``oload_types``).
+   7. Required DXIL Version with support for the operation.
+   8. Required minimum Shader Model (``shader_model``).
+   9. Minimum shader model required with translation by linker (``shader_model_translated``)
+   10.  List of shader stages applicable to (``shader_stages``), empty, if applicable to all stages.
+   11.  Memory access attributes of the operation (``fn_attr``).
+   12.  Boolean attributes of operation to indicate if it
+
+        * is some kind of a derivative (``is_derivative``)
+        * requires gradient calculation (``is_gradient``)
+        * is a sampler feedback (``is_feedback``)
+        * requires in-wave, cross-lane functionality (``is_wave``)
+        * requires that all of its inputs are uniform across the wave (``requires_uniform_inputs``).
+        * is a barrier operation (``is_barrier``).
 
 Motivation
 ==========
 
-DXIL backend passes depend on various properties of DXIL Operations. For example, ``DXILLowering``
+DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXIOpLLowering``
----------------
bogner wrote:

```suggestion
DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXILOpLowering``
```

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


More information about the llvm-commits mailing list