From c18008007e25f01f6e9c9e8e40e3a325d6d13b69 Mon Sep 17 00:00:00 2001 From: Bharadwaj Yadavalli Date: Wed, 12 Jun 2024 23:46:06 +0000 Subject: [PATCH 1/6] Update design doc with constraint specification --- llvm/docs/DirectX/DXILOpTableGenDesign.rst | 215 ++++++++++++++------- 1 file changed, 148 insertions(+), 67 deletions(-) diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst index 2b1e0901b5061..37caff9cf5e46 100644 --- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst +++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst @@ -41,14 +41,11 @@ A. Properties consumed in DXIL backend passes 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 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 + 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 for all. + 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``) @@ -70,86 +67,170 @@ analogous to ``hctdb.py`` for ``DirectXShadeCompiler`` repo. It needs to have a representation capabilities that TableGen backends (such as ``DXILEmitter``) can rely on. Additionally, the DXIL Op specification should be easy to read and comprehend. -This note focuses on specification of the set of properties consumed by DXIL backend -passes identified above in category A. Any of the properties from category B are expected to be -included as deemed necessary during implementation. +This note provides the design of the specification DXIL Ops as TableGen class ``DXILOp`` +by specifying its properties identified above. + +DXIL Operation Specification +============================ -Design -====== +The DXIL Operation is represented using the TableGen ``class DXILOp``. The DXIL operation +properties are specified as fields of the ``DXILOp`` class as described below. 1. Each DXIL Operation is represented as a TableGen record. The name of each of the records signifies operation name. -2. The LLVM Intrinsic that maps to the operation is represented using ``Intrinsic::*``. -3. The unique operation id is represented by an integer. -4. DXIL Operation Class is represented as follows +2. A documentation string for the operation. +3. The LLVM Intrinsic that maps to the operation is represented as ``Intrinsic`` defined in + `Intrinsics.td `_. +4. The unique operation id is represented by an integer. +5. DXIL Operation Class is represented as follows .. code-block:: // Abstraction of DXIL Operation class. - // It encapsulates an associated function signature viz., - // returnTy(param1Ty, param2Ty, ...) represented as a list of LLVMTypes. - // DXIL Ops that belong to a DXILOpClass record the signature of that DXILOpClass - - class DXILOpClass OpSig> { - list OpSignature = OpSig; - } + class DXILOpClass; Concrete operation classes, such as ``unary`` are defined inheriting from ``DXILOpClass``. -5. Valid overload types are represented as a list of ``LLVMType``. -6. Concrete records of DXIL versions and are defined by inheriting from the class +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``. .. code-block:: - // Abstract class to represent major and minor version values - class Version { - int Major = major; - int Minor = minor; - } + defvar dxil_overload_ty = llvm_any_ty -7. A documentation string for the operation. +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`` 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 properties described above. .. code-block:: - // Abstraction DXIL Operation - class DXILOpPropertiesBase { - int OpCode = 0; // Opcode of DXIL Operation - DXILOpClass OpClass = UnknownOpClass; // Class of DXIL Operation. - Intrinsic LLVMIntrinsic = ?; // LLVM Intrinsic DXIL Operation maps to - list OpOverloadTypes = ?; // Valid overload type - // of DXIL Operation - Version DXILVer = ?; // Min DXIL version - string Doc = ""; // A short description of the operation - } - - -The following convenience class, definitions of ``unary`` and ``DXVer1_0`` are used to -illustrate the definitions of ``Sin`` and ``Cos`` operations: - - .. code-block:: - - class DXILOpProperties overloadTypes, - string doc> : DXILOpPropertiesBase { - int OpCode = opCode; - Intrinsic LLVMIntrinsic = intrinsic; - list OpOverloadTypes = overloadTypes; - string Doc = doc; - } - - def unary : DXILOpClass<[llvm_any_ty, LLVMMatchType<0>]>; - def DXVer1_0 : Version<1, 0>; - - let OpClass = unary, DXILVer = DXVer1_0 in { - def Cos : DXILOpProperties<12, int_cos, [llvm_half_ty, llvm_float_ty], - "Returns cosine(theta) for theta in radians.">; - def Sin : DXILOpProperties<13, int_sin, [llvm_half_ty, llvm_float_ty], - "Returns sine(theta) for theta in radians.">; - } + // Abstraction DXIL Operation + class DXILOp { + // A short description of the operation + string Doc = ""; + + // Opcode of DXIL Operation + int OpCode = 0; + + // Class of DXIL Operation. + DXILOpClass OpClass = UnknownOpClass; + + // LLVM Intrinsic DXIL Operation maps to + Intrinsic LLVMIntrinsic = ?; + + // Dag containing the arguments of the op. Default to 0 arguments. + dag arguments = (ins); + + // Results of the op. Default to 0 results. + dag result = (out); + + // List of constraints predicated on Shader Model version + list sm_constraints; + + // Non-predicated operation attributes + dag attrtibutes = (attrs); + Version DXILVersion = ?; + } + +Constraint Specification +======================== + +DXIL Operation properties such as valid overload types and valid shader stages are +predicated on Shader Model version. + +Following is the definition of a generic constraint and the associated predicate + +.. code-block:: + + // Generic constraint + class Constraint { + Pred predicate = pred; + } + +Shader Model version is represented as follows: + +.. code-block:: + + // Abstract class to represent major and minor version values + class Version { + int Major = major; + int Minor = minor; + } + + // Valid Shader model version records + + // Definition of Shader Model 6.0 - 6.8 and DXIL Version 1.0 - 1.8 + foreach i = 0...8 in { + def SM6_#i : Version<6, i>; + def DX1_#i : Version<1, i>; + } + +A shader model version predicate class is defined as + +.. code-block:: + + class SMVersion : Pred { + Version SMVersion = ver; + } + +A constraint class to represent overload types and shader stages predicated on shader +model version is defined as + +.. code-block:: + + class SMVersionConstraints : Constraint { + dag overload_types = oloads; + dag stage_kinds = stages; + } + +The ``dag overload_types`` and ``dag shader_kinds``use a special markers ``overloads`` +and ``stages``, respectively. + + +Examples +-------- + +Consider a DXIL operation that is valid in Shader Model version 6.2 and later + + 1. wiith valid overload types ``half``, ``float``, ``i16`` and ``i32`` + 2. is valid for stages ``pixel`` and ``compute`` + 3. with valid overload types ``double`` and ``i614`` if Shader Model version 6.3 and later + 4. is valid for all stages if Shader Model version 6.3 and later + +This is represented as + +.. code-block:: + + [SMVersionConstraints, + (overloads llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty), + (stages pixel, compute)>, + SMVersionConstraints, + (overloads llvm_half_ty, llvm_float_ty, llvm_double_ty, + llvm_i16_ty, llvm_i32_ty, llvm_i64_ty), + (stages allKinds)>]; + +Consider a DXIL operation that is valid in Shader Model version 6.2 and later + + 1. with no overload types, i.e., types of all arguments and result are fixed. + 2. is valid for all stages. + +This is represented as + +.. code-block:: + + [SMVersionConstraints, (overloads), (stages allKinds)>]; + + +Attribute Specification +======================= Summary ======= From e3d630a6d5f822c203fe7479814777d42e77fb20 Mon Sep 17 00:00:00 2001 From: "S. Bharadwaj Yadavalli" Date: Thu, 13 Jun 2024 13:13:34 -0400 Subject: [PATCH 2/6] Populate section describing Attribute specification --- llvm/docs/DirectX/DXILOpTableGenDesign.rst | 94 ++++++++++++---------- 1 file changed, 53 insertions(+), 41 deletions(-) diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst index 37caff9cf5e46..f9d9cfb3831c7 100644 --- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst +++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst @@ -47,12 +47,12 @@ A. Properties consumed in DXIL backend passes 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``). + * 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 ========== @@ -104,8 +104,8 @@ properties are specified as fields of the ``DXILOp`` class as described below. 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`` class is described in a later section. + are represented as a ``dag`` using the special marker ``attrs``. Representation of ``Attributes`` + 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 properties described above. @@ -114,25 +114,25 @@ TableGen representations of its properties described above. // Abstraction DXIL Operation class DXILOp { - // A short description of the operation - string Doc = ""; + // A short description of the operation + string Doc = ""; - // Opcode of DXIL Operation - int OpCode = 0; + // Opcode of DXIL Operation + int OpCode = 0; - // Class of DXIL Operation. - DXILOpClass OpClass = UnknownOpClass; + // Class of DXIL Operation. + DXILOpClass OpClass = UnknownOpClass; - // LLVM Intrinsic DXIL Operation maps to - Intrinsic LLVMIntrinsic = ?; + // LLVM Intrinsic DXIL Operation maps to + Intrinsic LLVMIntrinsic = ?; - // Dag containing the arguments of the op. Default to 0 arguments. - dag arguments = (ins); + // Dag containing the arguments of the op. Default to 0 arguments. + dag arguments = (ins); - // Results of the op. Default to 0 results. - dag result = (out); + // Results of the op. Default to 0 results. + dag result = (out); - // List of constraints predicated on Shader Model version + // List of constraints predicated on Shader Model version list sm_constraints; // Non-predicated operation attributes @@ -144,7 +144,8 @@ Constraint Specification ======================== DXIL Operation properties such as valid overload types and valid shader stages are -predicated on Shader Model version. +predicated on Shader Model version.hese are represented as list of constrained +properties. Following is the definition of a generic constraint and the associated predicate @@ -152,7 +153,7 @@ Following is the definition of a generic constraint and the associated predicate // Generic constraint class Constraint { - Pred predicate = pred; + Pred predicate = pred; } Shader Model version is represented as follows: @@ -161,8 +162,8 @@ Shader Model version is represented as follows: // Abstract class to represent major and minor version values class Version { - int Major = major; - int Minor = minor; + int Major = major; + int Minor = minor; } // Valid Shader model version records @@ -178,7 +179,7 @@ A shader model version predicate class is defined as .. code-block:: class SMVersion : Pred { - Version SMVersion = ver; + Version SMVersion = ver; } A constraint class to represent overload types and shader stages predicated on shader @@ -187,23 +188,21 @@ model version is defined as .. code-block:: class SMVersionConstraints : Constraint { - dag overload_types = oloads; - dag stage_kinds = stages; + dag overload_types = oloads; + dag stage_kinds = stages; } -The ``dag overload_types`` and ``dag shader_kinds``use a special markers ``overloads`` +The ``dag overload_types`` and ``dag shader_kinds`` use a special markers ``overloads`` and ``stages``, respectively. - Examples --------- - -Consider a DXIL operation that is valid in Shader Model version 6.2 and later +--------- - 1. wiith valid overload types ``half``, ``float``, ``i16`` and ``i32`` - 2. is valid for stages ``pixel`` and ``compute`` - 3. with valid overload types ``double`` and ``i614`` if Shader Model version 6.3 and later - 4. is valid for all stages if Shader Model version 6.3 and later +Consider a DXIL Operation that is valid in Shader Model version 6.2 or later + 1. wiith valid overload types ``half``, ``float``, ``i16`` and ``i32`` + 2. is valid for stages ``pixel`` and ``compute`` + 3. with valid overload types ``double`` and ``i614`` if Shader Model version 6.3 and later + 4. is valid for all stages if Shader Model version 6.3 and later This is represented as @@ -218,20 +217,33 @@ This is represented as (stages allKinds)>]; Consider a DXIL operation that is valid in Shader Model version 6.2 and later - - 1. with no overload types, i.e., types of all arguments and result are fixed. - 2. is valid for all stages. + 1. with no overload types, i.e., types of all arguments and result are fixed. + 2. is valid for all stages. This is represented as .. code-block:: - [SMVersionConstraints, (overloads), (stages allKinds)>]; + [SMVersionConstraints, (overloads), (stages allKinds)>]; Attribute Specification ======================= +DXIL Operation properties that are not predicated on any constraint are represented as +a ``dag`` of Attribute records of the following abstract ``DXILAttributes`` class. + +.. code-block:: + + class DXILAttributes; + +Following example records represent memory arrtibutes + +.. code-block:: + + def ReadOnly : DXILOpAttributes; + def ReadNone : DXILOpAttributes; + Summary ======= From 790d13067eeabbecb99daa5cdce67b2646c2c274 Mon Sep 17 00:00:00 2001 From: "S. Bharadwaj Yadavalli" Date: Mon, 17 Jun 2024 11:50:26 -0400 Subject: [PATCH 3/6] Clean up and clarificationa --- llvm/docs/DirectX/DXILOpTableGenDesign.rst | 84 ++++++++++++---------- 1 file changed, 48 insertions(+), 36 deletions(-) diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst index f9d9cfb3831c7..28dd1ad4046ca 100644 --- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst +++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst @@ -14,36 +14,37 @@ Introduction encapsulates, among other information, various DXIL Operations in `hctdb.py `_. DXIL Operations are represented in one of the following `two ways -`_: +`_: #. 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..``. 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. + 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..``. 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 for all. + 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 @@ -57,24 +58,24 @@ A. Properties consumed in DXIL backend passes 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, ``DXILLowering`` pass will need information such as the DXIL operation an LLVM intrinsic is to be lowered to, along with valid overload and parameter types etc. The TableGen file - ``llvm/lib/Target/DirectX/DXIL.td`` - is used to represent DXIL Operations -by specifying their properties listed above. ``DXIL.td`` is designed to be the single source +by specifying their attributes listed above. ``DXIL.td`` is designed to be the single source of reference of DXIL Operations for DXIL backend implementation in ``llvm-project`` repo - analogous to ``hctdb.py`` for ``DirectXShadeCompiler`` repo. It needs to have a rich representation capabilities that TableGen backends (such as ``DXILEmitter``) can rely on. Additionally, the DXIL Op specification should be easy to read and comprehend. This note provides the design of the specification DXIL Ops as TableGen class ``DXILOp`` -by specifying its properties identified above. +by specifying its attributes identified above. DXIL Operation Specification ============================ -The DXIL Operation is represented using the TableGen ``class DXILOp``. The DXIL operation -properties are specified as fields of the ``DXILOp`` class as described below. +The DXIL Operation is represented using the TableGen class ``DXILOp``. The DXIL operation +attributes are specified as fields of the ``DXILOp`` class as described below. 1. Each DXIL Operation is represented as a TableGen record. The name of each of the records signifies operation name. @@ -89,7 +90,7 @@ properties are specified as fields of the ``DXILOp`` class as described below. // Abstraction of DXIL Operation class. class DXILOpClass; - Concrete operation classes, such as ``unary`` are defined inheriting from ``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 @@ -108,7 +109,7 @@ properties are specified as fields of the ``DXILOp`` class as described below. 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 properties described above. +TableGen representations of its attributes described above. .. code-block:: @@ -143,14 +144,17 @@ TableGen representations of its properties described above. Constraint Specification ======================== -DXIL Operation properties such as valid overload types and valid shader stages are -predicated on Shader Model version.hese are represented as list of constrained -properties. +DXIL Operation attributes such as valid overload types and valid shader stages are +predicated on Shader Model version. These are represented as list of constrained +attributes. Following is the definition of a generic constraint and the associated predicate .. code-block:: + // Primitive predicate + class Pred; + // Generic constraint class Constraint { Pred predicate = pred; @@ -198,11 +202,12 @@ and ``stages``, respectively. Examples --------- -Consider a DXIL Operation that is valid in Shader Model version 6.2 or later - 1. wiith valid overload types ``half``, ``float``, ``i16`` and ``i32`` - 2. is valid for stages ``pixel`` and ``compute`` - 3. with valid overload types ``double`` and ``i614`` if Shader Model version 6.3 and later - 4. is valid for all stages if Shader Model version 6.3 and later +Consider a DXIL Operation that is valid in Shader Model 6.2 and later, + +1. with valid overload types ``half``, ``float``, ``i16`` and ``i32`` +2. is valid for stages ``pixel`` and ``compute`` +3. with valid overload types ``double`` and ``i614`` if Shader Model version 6.3 and later +4. is valid for all stages if Shader Model version 6.3 and later This is represented as @@ -216,9 +221,10 @@ This is represented as llvm_i16_ty, llvm_i32_ty, llvm_i64_ty), (stages allKinds)>]; -Consider a DXIL operation that is valid in Shader Model version 6.2 and later - 1. with no overload types, i.e., types of all arguments and result are fixed. - 2. is valid for all stages. +Consider a DXIL operation that is valid in Shader Model version 6.2 and later, + +1. with no overload types, i.e., all argument typess and result type are fixed. +2. is valid for all stages. This is represented as @@ -227,10 +233,16 @@ This is represented as [SMVersionConstraints, (overloads), (stages allKinds)>]; +Specifying attributes predicated on Shader Model version using the single field +``sm_constraints`` not only allows for all of them to be specified together but +also allows for a single place to specify minimum shader model version that supports +the operation. Thus, a separate fiels is not needed to specify minimum shader model +version. + Attribute Specification ======================= -DXIL Operation properties that are not predicated on any constraint are represented as +DXIL Operation attributes that are not predicated on any constraint, are represented as a ``dag`` of Attribute records of the following abstract ``DXILAttributes`` class. .. code-block:: @@ -249,5 +261,5 @@ Summary This note sketches the design of a readable and maintainable TableGen specification of DXIL Ops in ``DXIL.td`` intended to serve as a single source of reference for TableGen -backends (such as ``DXILEmitter``) that generates C++ representations used in DXIL +backends (such as ``DXILEmitter``) that generate C++ representations used in DXIL backend passes. From 63ed65e1b1c7d44da6d78bd8fa128051dfd12412 Mon Sep 17 00:00:00 2001 From: "S. Bharadwaj Yadavalli" Date: Mon, 17 Jun 2024 16:13:27 -0400 Subject: [PATCH 4/6] Fix typo (PR feedback) --- llvm/docs/DirectX/DXILOpTableGenDesign.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst index 28dd1ad4046ca..5d0b3f522fbe0 100644 --- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst +++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst @@ -249,7 +249,7 @@ a ``dag`` of Attribute records of the following abstract ``DXILAttributes`` clas class DXILAttributes; -Following example records represent memory arrtibutes +Following example records represent memory attributes .. code-block:: From 93c141320d0fdbeda72911e70b489e7fbe5a9cfe Mon Sep 17 00:00:00 2001 From: "S. Bharadwaj Yadavalli" Date: Wed, 19 Jun 2024 11:21:20 -0400 Subject: [PATCH 5/6] Clarify design goal wording - per PR feedback --- llvm/docs/DirectX/DXILOpTableGenDesign.rst | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst index 5d0b3f522fbe0..5e8d96f929eb0 100644 --- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst +++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst @@ -58,15 +58,17 @@ A. Attributes consumed in DXIL backend passes Motivation ========== -DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXILLowering`` +DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXIOpLLowering`` pass will need information such as the DXIL operation an LLVM intrinsic is to be lowered to, along with valid overload and parameter types etc. The TableGen file - ``llvm/lib/Target/DirectX/DXIL.td`` - is used to represent DXIL Operations by specifying their attributes listed above. ``DXIL.td`` is designed to be the single source -of reference of DXIL Operations for DXIL backend implementation in ``llvm-project`` repo - -analogous to ``hctdb.py`` for ``DirectXShadeCompiler`` repo. It needs to have a rich -representation capabilities that TableGen backends (such as ``DXILEmitter``) can rely on. -Additionally, the DXIL Op specification should be easy to read and comprehend. +of reference of DXIL Operations primarily for the implementation of passes in DXIL backend in +``llvm-project`` repo - analogous to ``hctdb.py`` for ``DirectXShadeCompiler`` repo. However, +the current design does not intend to encapsulate various validation rules, present in ``hctdb.py``, +but do not pertain to DXIL Operations. It needs to have a rich representation capabilities that +TableGen backends (such as ``DXILEmitter``) can rely on. Additionally, the DXIL Op specification +should be easy to read and comprehend. This note provides the design of the specification DXIL Ops as TableGen class ``DXILOp`` by specifying its attributes identified above. From 1298a3fff7450c731dc30539fcfa824f39af6725 Mon Sep 17 00:00:00 2001 From: "S. Bharadwaj Yadavalli" Date: Wed, 19 Jun 2024 14:32:39 -0400 Subject: [PATCH 6/6] Add DXIL Op example and fix typo --- llvm/docs/DirectX/DXILOpTableGenDesign.rst | 26 +++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst index 5e8d96f929eb0..5f3ac75e82494 100644 --- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst +++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst @@ -58,7 +58,7 @@ A. Attributes consumed in DXIL backend passes Motivation ========== -DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXIOpLLowering`` +DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXILOpLowering`` pass will need information such as the DXIL operation an LLVM intrinsic is to be lowered to, along with valid overload and parameter types etc. The TableGen file - ``llvm/lib/Target/DirectX/DXIL.td`` - is used to represent DXIL Operations @@ -201,8 +201,8 @@ model version is defined as The ``dag overload_types`` and ``dag shader_kinds`` use a special markers ``overloads`` and ``stages``, respectively. -Examples ---------- +Examples of Constraints +----------------------- Consider a DXIL Operation that is valid in Shader Model 6.2 and later, @@ -258,6 +258,26 @@ Following example records represent memory attributes def ReadOnly : DXILOpAttributes; def ReadNone : DXILOpAttributes; +DXIL Operation Specification Example +==================================== +Following illustrates the specification of the DXIL Op ``Sin`` + +.. code-block:: + + def Sin : DXILOp { + let Doc ="Returns sine(theta) for theta in radians."; + let OpCode = 13; + let OpClass = unary; + let LLVMIntrinsic = int_sin; + let arguments = (ins LLVMMatchType<0>); + let result = (out dxil_overload_ty); + let sm_constraints = [SMVersionConstraints, + (overloads llvm_half_ty, llvm_float_ty), + (stages allKinds)>]; + let attributes = (attrs ReadNone); + let DXILVersion = DX1_0; + } + Summary =======