[llvm] [DXIL][Doc] Update specification of TableGen DXIL properties (PR #99055)
S. Bharadwaj Yadavalli via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 22 13:16:52 PDT 2024
https://github.com/bharadwajy updated https://github.com/llvm/llvm-project/pull/99055
>From 70908142d1f37640a2da1ab9c712b1e7729b42c6 Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Tue, 16 Jul 2024 10:42:52 -0400
Subject: [PATCH 1/7] [DXIL][Doc] Update specification of constraints to use
TableGen list instead of dag. Add related additional details.
---
llvm/docs/DirectX/DXILOpTableGenDesign.rst | 301 ++++++++++++++-------
1 file changed, 201 insertions(+), 100 deletions(-)
diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
index 5f3ac75e82494..7ee37e27614db 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -24,12 +24,12 @@ DXIL Operations are represented in one of the following `two ways
These are collectively referred to as `LLVM Intrinsics` in this note.
-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,
+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 consumed in DXIL backend passes as well as in other usage scenarios such as validation,
DXIL reader, etc.
-A. Attributes consumed in DXIL backend passes
+A. Properties consumed in DXIL backend passes
1. Name of operation (``dxil_op``)
2. A string that documents the operation (``doc``) - This is not strictly necessary but is included
@@ -38,7 +38,7 @@ A. Attributes consumed in DXIL backend passes
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
+ 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.
@@ -58,26 +58,26 @@ A. Attributes consumed in DXIL backend passes
Motivation
==========
-DXIL backend passes depend on various attributes of DXIL Operations. For example, ``DXILOpLowering``
+DXIL backend passes depend on various properties 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 -
+along with valid overload and argument 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 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
+by specifying their properties listed above. ``DXIL.td`` is designed to be the single source
+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.
+by specifying its properties identified above.
DXIL Operation Specification
============================
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.
+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.
@@ -93,8 +93,10 @@ 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
+6. A non-``void`` return type of the operation is represented as a list with one ``LLVMType``.
+ A ``void`` return is represented as a null-list, ``[]``.
+7. Non-zero count of 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 ``dxil_overload_ty`` in the argument or in the result, where
``dxil_overload_ty`` is defined to be synonymous to ``llvm_any_ty``.
@@ -102,16 +104,19 @@ attributes are specified as fields of the ``DXILOp`` class as described below.
defvar dxil_overload_ty = llvm_any_ty
+ Use of TableGen class ``LLVMMatchType`` is supported to match type of another argument.
-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
+8. Valid overload types and shader stages predicated on Shader Model version are specified
+ as a list of ``Constraints`` 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.
+9. Various attributes of the DXIL Operation are represented as a ``list`` of ``Attribute`` class
+ records. Representation of ``Attribute`` class is described in a later section.
+
+10. DXIL Version is represented as a record of class ``DXILVersion``, whose details are provided
+ 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.
+TableGen representations of its properties described above.
.. code-block::
@@ -127,42 +132,27 @@ TableGen representations of its attributes described above.
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<SMVersionConstraints> sm_constraints;
-
- // Non-predicated operation attributes
- dag attrtibutes = (attrs);
- Version DXILVersion = ?;
- }
-
-Constraint Specification
-========================
+ Intrinsic LLVMIntrinsic = ? ;
-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.
+ // List of argument types of the op. Default to 0 arguments.
+ list<LLVMType> arguments = [];
-Following is the definition of a generic constraint and the associated predicate
+ // List of result types of the op. Default to 0 results.
+ list<LLVMType> result = [];
-.. code-block::
+ list<Constraints> constraints = [];
- // Primitive predicate
- class Pred;
+ // Operation attributes
+ list<DXILAttribute> attributes = [];
- // Generic constraint
- class Constraint<Pred pred> {
- Pred predicate = pred;
+ Version DXILVersion = ? ;
}
-Shader Model version is represented as follows:
+Version Specification
+=====================
+
+A ``Version`` class encapsulating ``Major`` and ``Minor`` version number is defined
+as follows:
.. code-block::
@@ -172,7 +162,10 @@ Shader Model version is represented as follows:
int Minor = minor;
}
- // Valid Shader model version records
+
+Concrete representations of valid Shader Model and DXIL versions are defined as follows:
+
+.. code-block::
// Definition of Shader Model 6.0 - 6.8 and DXIL Version 1.0 - 1.8
foreach i = 0...8 in {
@@ -180,6 +173,44 @@ Shader Model version is represented as follows:
def DX1_#i : Version<1, i>;
}
+Shader Stage Specification
+==========================
+
+Various shader stages such as ``compute``, ``pixel``, ``vertex``, etc., are represented as
+follows
+
+.. code-block::
+
+ // Shader stages
+ class ShaderStage;
+
+ def compute : ShaderStage;
+ def pixel : ShaderStage;
+ def vertex : ShaderStage;
+ ...
+
+Constraint Specification
+========================
+
+DXIL Operation properties such as valid overload types and valid shader stages are
+predicated on Shader Model version. These are represented as list of constraints.
+
+Following is the class representing a predicate and a constraint class representing
+a ``list<Pred> l`` of properties applicable to the DXIL Operation predicated on
+``Pred p``.
+
+.. code-block::
+
+ // Primitive predicate
+ class Pred;
+
+ // Generic constraint
+ class Constraints<Pred p, list<Pred> l = []> : Pred {
+ Pred pred = p;
+ list<Pred> constraints = l;
+ }
+
+
A shader model version predicate class is defined as
.. code-block::
@@ -188,96 +219,166 @@ A shader model version predicate class is defined as
Version SMVersion = ver;
}
-A constraint class to represent overload types and shader stages predicated on shader
-model version is defined as
+Overload type predicates are represented as records of the class
.. code-block::
- class SMVersionConstraints<SMVersion smver, dag oloads, dag stages> : Constraint<smver> {
- dag overload_types = oloads;
- dag stage_kinds = stages;
+ class Overloads<list<LLVMType> tys> : Pred {
+ list<LLVMType> overload_types = tys;
+ }
+
+Shader Stage predicates are represented as records of class
+
+.. code-block::
+
+ class Stages<list<ShaderStage> st> : Pred {
+ list<ShaderStage> stage_kinds = st;
}
-The ``dag overload_types`` and ``dag shader_kinds`` use a special markers ``overloads``
-and ``stages``, respectively.
+Overload and shader stages constrained by Shader Model version are expressed by
+composing the above predicate records.
-Examples of Constraints
------------------------
+If no constraints are specified for a DXIL operation, it is assumed to
-Consider a DXIL Operation that is valid in Shader Model 6.2 and later,
+a) be supported in Shader Model 6.0 and later.
+b) have no overload types
+c) be supported in all shader stage kinds
-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
+If a constraint is specified, one or both of the Overload type and shader kind
+constraints can be omitted when appropriate.
-This is represented as
+Examples of Constraint Specification
+------------------------------------
-.. code-block::
+1. Consider a DXIL Operation with the following properties,
- [SMVersionConstraints<SMVersion<SM6_2>,
- (overloads llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty),
- (stages pixel, compute)>,
- SMVersionConstraints<SMVersion<SM6_3>,
- (overloads llvm_half_ty, llvm_float_ty, llvm_double_ty,
- llvm_i16_ty, llvm_i32_ty, llvm_i64_ty),
- (stages allKinds)>];
+ 1. In Shader Model 6.2 and later
-Consider a DXIL operation that is valid in Shader Model version 6.2 and later,
+ a) supports overload types ``half``, ``float``, ``i16`` and ``i32`` and
+ b) is valid for stages ``pixel`` and ``compute``
-1. with no overload types, i.e., all argument typess and result type are fixed.
-2. is valid for all stages.
+ 2. In Shader Model 6.3 and later
-This is represented as
+ a) supports additional valid overload types ``double`` and ``i64`` and
+ b) is valid for all stages
-.. code-block::
+ The constraints of such an operation are represented as
+
+ .. code-block::
+
+ constraints = [Constraints<SMVersion<SM6_2>,
+ [Overloads<[llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty]>,
+ Stages<[pixel, compute]>]>,
+ Constraints<SMVersion<SM6_3>,
+ [Overloads<[llvm_half_ty, llvm_float_ty, llvm_double_ty,
+ llvm_i16_ty, llvm_i32_ty, llvm_i64_ty]>]];
+
+ Note that ``Stage<>`` predicate is not specified for the constraint predicated for
+ ``SM6_3`` to signify that the operation is valid in all shader stages in Shader Model
+ version 6.3.
- [SMVersionConstraints<SMVersion<SM6_2>, (overloads), (stages allKinds)>];
+2. Consider a DXIL operation that is valid in Shader Model version 6.2 and later,
+ 1. with no overload types, i.e., all argument types and result type are fixed.
+ 2. is valid for all stages.
-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
+ This is represented as
+
+ .. code-block::
+
+ [Constraints<SMVersion<SM6_2>, []];
+
+Specifying properties predicated on Shader Model version using the field
+``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
+the operation. Thus, a separate field is not needed to specify minimum shader model
version.
Attribute Specification
=======================
DXIL Operation attributes that are not predicated on any constraint, are represented as
-a ``dag`` of Attribute records of the following abstract ``DXILAttributes`` class.
+a ``list`` of Attribute records of ``DXILAttributes`` class.
.. code-block::
class DXILAttributes;
-Following example records represent memory attributes
+Following example records represent memory attributes
.. code-block::
def ReadOnly : DXILOpAttributes;
def ReadNone : DXILOpAttributes;
-DXIL Operation Specification Example
-====================================
-Following illustrates the specification of the DXIL Op ``Sin``
+DXIL Operation Specification Examples
+=====================================
+
+A convenience class ``DXILOpAndCLass`` is defined to specify the minimal properties
+of a ``DXILOp`` as follows.
.. code-block::
- def Sin : DXILOp {
- let Doc ="Returns sine(theta) for theta in radians.";
- let OpCode = 13;
- let OpClass = unary;
+ class DXILOpAndClass<int opcode, DXILOpClass opcalss> : DXILOp {
+ int OpCode = opcode;
+ DXILOpClass OpClass = opcalss;
+ }
+
+Following examples illustrate the specification of some of the DXIL Ops
+
+``Sin`` operation valid in SM 6.0 for all shader stages but with overload types constraints.
+
+.. code-block::
+
+ def Sin : DXILOpAndClass<13, unary> {
+ let Doc = "Returns sine(theta) for theta in radians.";
let LLVMIntrinsic = int_sin;
- let arguments = (ins LLVMMatchType<0>);
- let result = (out dxil_overload_ty);
- let sm_constraints = [SMVersionConstraints<SMVersion<SM6_0>,
- (overloads llvm_half_ty, llvm_float_ty),
- (stages allKinds)>];
- let attributes = (attrs ReadNone);
+ let arguments = [LLVMMatchType<0>];
+ let result = [dxil_overload_ty];
+ let constraints = [
+ Constraints<SMVersion<SM6_0>, [Overloads<[llvm_half_ty, llvm_float_ty]>]>
+ ];
+ let attributes = [ReadNone];
let DXILVersion = DX1_0;
}
+
+``FlattenedThreadIdInGroup`` operation valid in SM 6.0 with shader stage validity
+constraints; with fixed argument type, hence no valid overload type and ``void``
+return type, hence ``result`` field not specified.
+
+.. code-block::
+
+ def FlattenedThreadIdInGroup : DXILOpAndClass<96, flattenedThreadIdInGroup> {
+ let Doc = "Provides a flattened index for a given thread within a given "
+ "group (SV_GroupIndex)";
+ let LLVMIntrinsic = int_dx_flattened_thread_id_in_group;
+ let arguments = [llvm_i32_ty];
+ let constraints =
+ [Constraints<SMVersion<SM6_0>,
+ [Stages<[compute, mesh, amplification, node]>]>];
+ let attributes = [ReadNone];
+ let DXILVersion = DX1_0;
+ }
+
+``RawBufferStore`` operation with different valid overload types for SM 6.2+ and SM 6.3+.
+
+.. code-block::
+
+ def RawBufferStore : DXILOpAndClass<140, rawBufferStore> {
+ let Doc = "Writes to a RWByteAddressBuffer or RWStructuredBuffer.";
+ let LLVMIntrinsic = int_rwbuffer_store;
+ let arguments = [llvm_i32_ty, dxil_resource_ty, llvm_i32_ty, llvm_i32_ty, dxil_overload_ty,
+ dxil_overload_ty, dxil_overload_ty, dxil_overload_ty, llvm_i8_ty, llvm_i32_ty];
+ let constraints = [Constraints<SMVersion<SM6_2>,
+ [Overloads<[llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty]>]>,
+ Constraints<SMVersion<SM6_3>,
+ [Overloads<[llvm_half_ty, llvm_float_ty, llvm_double_ty,
+ llvm_i16_ty, llvm_i32_ty, llvm_i64_ty]>]>];
+ let DXILVersion = DX1_2;
+ }
+
+
Summary
=======
>From 39ddc2b6bf2d12411c20e05f8d060fc8918a07ed Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Wed, 17 Jul 2024 13:16:53 -0400
Subject: [PATCH 2/7] Incorporate PR feedback.
---
llvm/docs/DirectX/DXILOpTableGenDesign.rst | 357 ++++++++++++---------
1 file changed, 203 insertions(+), 154 deletions(-)
diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
index 7ee37e27614db..74760aa15b56c 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -93,64 +93,79 @@ properties 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. A non-``void`` return type of the operation is represented as a list with one ``LLVMType``.
- A ``void`` return is represented as a null-list, ``[]``.
-7. Non-zero count of operation arguments are represented as a list of ``LLVMType`` with each type
+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 ``dxil_overload_ty`` in the argument or in the result, where
- ``dxil_overload_ty`` is defined to be synonymous to ``llvm_any_ty``.
+ 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
- Use of TableGen class ``LLVMMatchType`` is supported to match type of another argument.
+ Empty list, ``[]`` represents an operation with no arguments.
-8. Valid overload types and shader stages predicated on Shader Model version are specified
- as a list of ``Constraints`` records. Representation of ``Constraints`` class is described
- a later section.
-9. Various attributes of the DXIL Operation are represented as a ``list`` of ``Attribute`` class
- records. Representation of ``Attribute`` class is described in a later section.
+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.
-10. DXIL Version is represented as a record of class ``DXILVersion``, whose details are provided
- in a later section.
+Types specific to DXIL
+----------------------
-A DXIL Operation is represented by the following TableGen class by encapsulating the various
+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 = ? ;
+ Intrinsic LLVMIntrinsic = ?;
+
+ // Result type of the op.
+ list<LLVMType> result = [];
// List of argument types of the op. Default to 0 arguments.
list<LLVMType> arguments = [];
- // List of result types of the op. Default to 0 results.
- list<LLVMType> result = [];
-
- list<Constraints> constraints = [];
+ // List of valid overload types predicated by DXIL version
+ list<VersionedOverloads> overloads;
- // Operation attributes
- list<DXILAttribute> attributes = [];
+ // List of valid shader stages predicated by DXIL version
+ list<VersionedStages> stages;
- Version DXILVersion = ? ;
+ // List of valid attributes predicated by DXIL version
+ list<VersionedAttributes> versioned_attributes = [];
}
Version Specification
=====================
+DXIL version is used to specify various version-dependent operation properties in
+place of Shader Model version.
+
A ``Version`` class encapsulating ``Major`` and ``Minor`` version number is defined
as follows:
@@ -163,21 +178,20 @@ as follows:
}
-Concrete representations of valid Shader Model and DXIL versions are defined as follows:
+Concrete representations of valid DXIL versions are defined as follows:
.. code-block::
- // Definition of Shader Model 6.0 - 6.8 and DXIL Version 1.0 - 1.8
+ // Definition of DXIL Version 1.0 - 1.8
foreach i = 0...8 in {
- def SM6_#i : Version<6, i>;
- def DX1_#i : Version<1, i>;
+ def DXIL1_#i : Version<1, i>;
}
Shader Stage Specification
==========================
-Various shader stages such as ``compute``, ``pixel``, ``vertex``, etc., are represented as
-follows
+Various shader stages such as ``compute``, ``pixel``, ``vertex``, etc., are represented
+as follows
.. code-block::
@@ -189,195 +203,230 @@ follows
def vertex : ShaderStage;
...
-Constraint Specification
-========================
+Shader Attribute Specification
+==============================
-DXIL Operation properties such as valid overload types and valid shader stages are
-predicated on Shader Model version. These are represented as list of constraints.
-
-Following is the class representing a predicate and a constraint class representing
-a ``list<Pred> l`` of properties applicable to the DXIL Operation predicated on
-``Pred p``.
+Various operation memory access and boolean attributes such as ``ReadNone``,
+``IsWave`` etc., are represented as follows
.. code-block::
- // Primitive predicate
- class Pred;
+ class DXILAttribute;
- // Generic constraint
- class Constraints<Pred p, list<Pred> l = []> : Pred {
- Pred pred = p;
- list<Pred> constraints = l;
- }
+ def ReadOnly : DXILOpAttributes;
+ def ReadNone : DXILOpAttributes;
+ def IsWave : DXILOpAttributes;
+ ...
+Constrained Specification
+=========================
-A shader model version predicate class is defined as
+DXIL Operation properties such as valid overload types, shader stages and
+attributes are predicated on DXIL version. These are represented as list of
+versioned constraints.
-.. code-block::
+Overload Type Specification
+---------------------------
- class SMVersion<Version ver> : Pred {
- Version SMVersion = ver;
- }
-
-Overload type predicates are represented as records of the class
+``overloads`` field of ``class DXILOp`` is used to represent valid operation
+overloads predicated on DXIL version as list of records of the following class
.. code-block::
- class Overloads<list<LLVMType> tys> : Pred {
- list<LLVMType> overload_types = tys;
- }
+ class VersionedOverloads<Version minver, list<LLVMType> ols> {
+ Version dxil_version = minver;
+ list<LLVMType> overload_types = ols;
+ }
-Shader Stage predicates are represented as records of class
+Following is an example specification of valid overload types for ``DXIL1_0`` and
+``DXIL1_2``.
.. code-block::
- class Stages<list<ShaderStage> st> : Pred {
- list<ShaderStage> stage_kinds = st;
- }
-
-Overload and shader stages constrained by Shader Model version are expressed by
-composing the above predicate records.
+ overloads = [
+ VersionedOverloads<DXIL1_0, [halfTy, floatTy]>,
+ VersionedOverloads<DXIL1_2, [halfTy, floatTy, doubleTy]>
+ ];
-If no constraints are specified for a DXIL operation, it is assumed to
+An empty list signifies that the operation supports no overload types.
-a) be supported in Shader Model 6.0 and later.
-b) have no overload types
-c) be supported in all shader stage kinds
-If a constraint is specified, one or both of the Overload type and shader kind
-constraints can be omitted when appropriate.
+Stages Specification
+--------------------
-Examples of Constraint Specification
-------------------------------------
+``stages`` field of ``class DXILOp`` is used to represent valid operation
+stages predicated on DXIL version as list of records of the following class
-1. Consider a DXIL Operation with the following properties,
+.. code-block::
- 1. In Shader Model 6.2 and later
+ class VersionedStages<Version minver, list<ShaderStage> sts> {
+ Version dxil_version = minver;
+ list<ShaderStage> shader_stages = sts;
+ }
- a) supports overload types ``half``, ``float``, ``i16`` and ``i32`` and
- b) is valid for stages ``pixel`` and ``compute``
+Following is an example specification of valid stages for ``DXIL1_0``,
+``DXIL1_2``, ``DXIL1_4`` and ``DXIL1_6``.
- 2. In Shader Model 6.3 and later
+.. code-block::
- a) supports additional valid overload types ``double`` and ``i64`` and
- b) is valid for all stages
+ stages = [
+ VersionedStages<DXIL1_0, [compute, pixel]>,
+ VersionedStages<DXIL1_2, [compute, pixel, mesh]>,
+ VersionedStages<DXIL1_4, [all_stages]>,
+ VersionedStages<DXIL1_6, [removed]>
+ ];
- The constraints of such an operation are represented as
+The following two pseudo stage records in addition to standard shader stages
+are defined.
- .. code-block::
+1. ``all_stages`` signifies that the operation is valid for all stages in the
+ specified DXIL version and later.
+2. ``removed`` signifies removal of support for the operation in the specified
+ DXIL version and later.
- constraints = [Constraints<SMVersion<SM6_2>,
- [Overloads<[llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty]>,
- Stages<[pixel, compute]>]>,
- Constraints<SMVersion<SM6_3>,
- [Overloads<[llvm_half_ty, llvm_float_ty, llvm_double_ty,
- llvm_i16_ty, llvm_i32_ty, llvm_i64_ty]>]];
+A non-empty list of supported stages is required to be specified. If an operation
+is supported in all DXIL versions and all stages it is required to be specified as
- Note that ``Stage<>`` predicate is not specified for the constraint predicated for
- ``SM6_3`` to signify that the operation is valid in all shader stages in Shader Model
- version 6.3.
+.. code-block::
-2. Consider a DXIL operation that is valid in Shader Model version 6.2 and later,
+ stages = [VersionedStages<DXIL1_0, [all_stages]>];
- 1. with no overload types, i.e., all argument types and result type are fixed.
- 2. is valid for all stages.
- This is represented as
- .. code-block::
+Attribute Specification
+-----------------------
- [Constraints<SMVersion<SM6_2>, []];
+``attributes`` field of ``class DXILOp`` is used to represent valid operation
+attributes predicated on DXIL version as list of records of the following class
-Specifying properties predicated on Shader Model version using the field
-``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 field is not needed to specify minimum shader model
-version.
+.. code-block::
-Attribute Specification
-=======================
+ class VersionedAttributes<MinVersion minver, list<DXILAttribute> attrs> {
+ MinVersion dxil_version = ver;
+ list<DXILAttribute> attributes = attrs;
+ }
-DXIL Operation attributes that are not predicated on any constraint, are represented as
-a ``list`` of Attribute records of ``DXILAttributes`` class.
+Following is an example specification of valid attributes for ``DXIL1_0``.
.. code-block::
- class DXILAttributes;
+ attributes = [VersionedAttributes<DXIL1_0, [ReadNone]];
-Following example records represent memory attributes
+A null list of ``attributes`` signifies no operation attributes.
-.. code-block::
+Each of the constraints states that the specified overload type, stage or
+attribute records are valid for the predicated DXIL version. Only
+the constraints corresponding to latest minimal DXIL version is applicable.
+Note as in the above example, any overload types, stages or attributes,
+that remain valid in a later DXIL version need to be specified in full.
+This provides the flexibility to specify constraints independent
+of others in the list.
- def ReadOnly : DXILOpAttributes;
- def ReadNone : DXILOpAttributes;
DXIL Operation Specification Examples
=====================================
-A convenience class ``DXILOpAndCLass`` is defined to specify the minimal properties
-of a ``DXILOp`` as follows.
+Following examples illustrate the specification of some of the DXIL Ops.
+
+``Sin`` operation - an operation valid in all DXIL versions and all stages
+and has valid overload types predicated on DXIL version.
.. code-block::
- class DXILOpAndClass<int opcode, DXILOpClass opcalss> : DXILOp {
- int OpCode = opcode;
- DXILOpClass OpClass = opcalss;
+ def Sin : DXILOp<13, unary> {
+ let Doc = "Returns sine(theta) for theta in radians.";
+ let LLVMIntrinsic = int_sin;
+ let result = overloadTy;
+ let arguments = [overloadTy];
+ let overloads = [VersionedOverloads<DXIL1_0, [halfTy, floatTy]>];
+ let stages = [VersionedStages<DXIL1_0, [all_stages]>];
+ let attributes = [VersionedAttributes<DXIL1_0, [ReadNone]>];
}
-Following examples illustrate the specification of some of the DXIL Ops
-
-``Sin`` operation valid in SM 6.0 for all shader stages but with overload types constraints.
+``FlattenedThreadIdInGroup`` - an operation with no arguments, no
+overload types, and valid stages and attributes predicated by DXIL Version.
.. code-block::
- def Sin : DXILOpAndClass<13, unary> {
- let Doc = "Returns sine(theta) for theta in radians.";
- let LLVMIntrinsic = int_sin;
- let arguments = [LLVMMatchType<0>];
- let result = [dxil_overload_ty];
- let constraints = [
- Constraints<SMVersion<SM6_0>, [Overloads<[llvm_half_ty, llvm_float_ty]>]>
- ];
- let attributes = [ReadNone];
- let DXILVersion = DX1_0;
- }
+ def FlattenedThreadIdInGroup : DXILOp<96, flattenedThreadIdInGroup> {
+ let Doc = "Provides a flattened index for a given thread within a given "
+ "group (SV_GroupIndex)";
+ let LLVMIntrinsic = int_dx_flattened_thread_id_in_group;
+ let result = i32Ty;
+ let stages = [VersionedStages<DXIL1_0, [compute, mesh, amplification, node]>];
+ let attributes = [VersionedAttributes<DXIL1_0, [ReadNone]>];
+ }
+
+``RawBufferStore`` - an operation with ``void`` return type, valid overload types
+predicated by DXIL Version and valid in all DXIL versions and stages.
+.. code-block::
+
+ def RawBufferStore : DXILOp<140, rawBufferStore> {
+ let Doc = "Writes to a RWByteAddressBuffer or RWStructuredBuffer.";
+ let result = voidTy;
+ let arguments = [dxil_resource_ty, i32Ty, i32Ty, overloadTy,
+ overloadTy, overloadTy, overloadTy, i8Ty, i32Ty];
+ let overloads = [
+ VersionedOverloads<DXIL1_2, [halfTy, floatTy, i16Ty, i32Ty]>,
+ VersionedOverloads<DXIL1_3>,[halfTy, floatTy, doubleTy,
+ i16Ty, i32Ty, i64Ty]>
+ ];
+ let stages = [VersionedStages<DXIL1_2, all_stages>];
+ let attributes = [VersionedAttributes<DXIL1_0, [ReadOnly]>];
+ }
-``FlattenedThreadIdInGroup`` operation valid in SM 6.0 with shader stage validity
-constraints; with fixed argument type, hence no valid overload type and ``void``
-return type, hence ``result`` field not specified.
+``DerivCoarseX`` - an operation with no overload types and stages predicated
+by DXIL Version.
.. code-block::
- def FlattenedThreadIdInGroup : DXILOpAndClass<96, flattenedThreadIdInGroup> {
- let Doc = "Provides a flattened index for a given thread within a given "
- "group (SV_GroupIndex)";
- let LLVMIntrinsic = int_dx_flattened_thread_id_in_group;
- let arguments = [llvm_i32_ty];
- let constraints =
- [Constraints<SMVersion<SM6_0>,
- [Stages<[compute, mesh, amplification, node]>]>];
- let attributes = [ReadNone];
- let DXILVersion = DX1_0;
+ def DerivCoarseX : DXILOp<83, unary> {
+ let doc = "Computes the rate of change per stamp in x direction.";
+ let LLVMIntrinsic = int_dx_ddx;
+ let result = overloadTy;
+ let arguments = [overloadTy];
+ let stages = [
+ Versioned<DXIL1_0, [library, pixel]>,
+ Versioned<DXIL1_6, [library, pixel, amplification, compute, mesh]>
+ ];
+ let attributes = [VersionedAttributes<DXIL1_0, [ReadNone]>];
}
-``RawBufferStore`` operation with different valid overload types for SM 6.2+ and SM 6.3+.
+``CreateHandle`` - an operation with no overload types, no associated ``LLVMIntrinsic``
+and stages predicated by DXIL Version.
.. code-block::
- def RawBufferStore : DXILOpAndClass<140, rawBufferStore> {
- let Doc = "Writes to a RWByteAddressBuffer or RWStructuredBuffer.";
- let LLVMIntrinsic = int_rwbuffer_store;
- let arguments = [llvm_i32_ty, dxil_resource_ty, llvm_i32_ty, llvm_i32_ty, dxil_overload_ty,
- dxil_overload_ty, dxil_overload_ty, dxil_overload_ty, llvm_i8_ty, llvm_i32_ty];
- let constraints = [Constraints<SMVersion<SM6_2>,
- [Overloads<[llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty]>]>,
- Constraints<SMVersion<SM6_3>,
- [Overloads<[llvm_half_ty, llvm_float_ty, llvm_double_ty,
- llvm_i16_ty, llvm_i32_ty, llvm_i64_ty]>]>];
- let DXILVersion = DX1_2;
+ def CreateHandle : DXILOp<57, createHandle> {
+ let doc = "Creates the handle to a resource";
+ let result = i32Ty;
+ let arguments = [i8Ty, i32Ty, i32Ty, i1Ty];
+ let stages = [
+ Versioned<DXIL1_0, [all_stages]>,
+ Versioned<DXIL1_6, [removed]
+ ];
+ let attributes = [VersionedAttributes<DXIL1_0, [ReadOnly]>];
}
+``Sample`` - an operation with valid overload types, stages and attributes
+predicated by DXIL version.
+
+.. code-block::
+
+ def Sample : DXILOp<60, sample> {
+ let Doc = "Samples a texture";
+ let LLVMIntrinsic = int_dx_sample;
+ let result = resRetF32Ty;
+ let arguments = [handleTy, handleTy, floatTy, floatTy, floatTy, floatTy,
+ i32Ty, i32Ty, i32Ty, floatTy];
+ let overloads = [Versioned<DXIL1_0, [halfTy, floatTy, i16Ty, i32Ty]>];
+ let stages = [
+ Versioned<DXIL1_0, [library, pixel]>,
+ Versioned<DXIL1_6, [library, pixel, amplification, compute, mesh]>
+ ];
+ let attributes = [VersionedAttributes<DXIL1_0, [ReadOnly]>];
+ }
Summary
=======
>From 0a0b652663dff95b47cf1f21534700214baca2ea Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Mon, 22 Jul 2024 13:43:53 -0400
Subject: [PATCH 3/7] Fix typo
---
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 74760aa15b56c..87d0dddcaf48d 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -145,7 +145,7 @@ TableGen representations of its properties described above.
Intrinsic LLVMIntrinsic = ?;
// Result type of the op.
- list<LLVMType> result = [];
+ LLVMType> result;
// List of argument types of the op. Default to 0 arguments.
list<LLVMType> arguments = [];
>From 101489d8e203c3c521a96539b80331c0e6ba2644 Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Mon, 22 Jul 2024 13:51:05 -0400
Subject: [PATCH 4/7] Rename ShaderStage to DXILShaderStage
---
llvm/docs/DirectX/DXILOpTableGenDesign.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
index 87d0dddcaf48d..10bcfb949d9b2 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -196,11 +196,11 @@ as follows
.. code-block::
// Shader stages
- class ShaderStage;
+ class DXILShaderStage;
- def compute : ShaderStage;
- def pixel : ShaderStage;
- def vertex : ShaderStage;
+ def compute : DXILShaderStage;
+ def pixel : DXILShaderStage;
+ def vertex : DXILShaderStage;
...
Shader Attribute Specification
@@ -259,9 +259,9 @@ stages predicated on DXIL version as list of records of the following class
.. code-block::
- class VersionedStages<Version minver, list<ShaderStage> sts> {
+ class VersionedStages<Version minver, list<DXILShaderStage> sts> {
Version dxil_version = minver;
- list<ShaderStage> shader_stages = sts;
+ list<DXILShaderStage> shader_stages = sts;
}
Following is an example specification of valid stages for ``DXIL1_0``,
>From 8f38f54e09225d9384f7368019f63dcc0e8aab26 Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Mon, 22 Jul 2024 14:06:19 -0400
Subject: [PATCH 5/7] Add sub-section title and an example for additional
clarification of multiple constraint specification.
---
llvm/docs/DirectX/DXILOpTableGenDesign.rst | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
index 10bcfb949d9b2..56422bf8e06db 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -292,7 +292,6 @@ is supported in all DXIL versions and all stages it is required to be specified
stages = [VersionedStages<DXIL1_0, [all_stages]>];
-
Attribute Specification
-----------------------
@@ -314,11 +313,27 @@ Following is an example specification of valid attributes for ``DXIL1_0``.
A null list of ``attributes`` signifies no operation attributes.
+Interpretation of Multiple Constraint Specification
+---------------------------------------------------
+
Each of the constraints states that the specified overload type, stage or
attribute records are valid for the predicated DXIL version. Only
the constraints corresponding to latest minimal DXIL version is applicable.
Note as in the above example, any overload types, stages or attributes,
that remain valid in a later DXIL version need to be specified in full.
+For example, consider the following specification of valid overload types:
+
+.. code-block::
+
+ overloads = [
+ VersionedOverloads<DXIL1_0, [halfTy, floatTy]>,
+ VersionedOverloads<DXIL1_2, [halfTy, floatTy, doubleTy]>
+ ];
+
+It specifies that the overload types ``halfTy`` and ``floatTy`` are valid for DXIL
+version 1.0 and later. It also specifies that ``doubleTy`` is additionally supported
+in DXIL version 1.2 and later.
+
This provides the flexibility to specify constraints independent
of others in the list.
>From 7511c3f6fc4bd92f7517a29d6fbb5cc5d342a30f Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Mon, 22 Jul 2024 15:01:14 -0400
Subject: [PATCH 6/7] Changes flagged by PR feedback.
---
llvm/docs/DirectX/DXILOpTableGenDesign.rst | 78 +++++++++++-----------
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
index 56422bf8e06db..fca81117e9870 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -106,13 +106,13 @@ properties are specified as fields of the ``DXILOp`` class as described below.
Empty list, ``[]`` represents an operation with no arguments.
8. Valid operation overload types predicated on DXIL version are specified as
- a list of ``VersionedOverloads`` records. Representation of ``VersionedOverloads``
+ a list of ``Overloads`` records. Representation of ``Overloads``
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
+ ``Stages`` records. Representation of ``Stages`` 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``
+ ``Attributes`` class records. Representation of ``Attributes``
class is described in a later section.
Types specific to DXIL
@@ -145,19 +145,19 @@ TableGen representations of its properties described above.
Intrinsic LLVMIntrinsic = ?;
// Result type of the op.
- LLVMType> result;
+ LLVMType result;
// List of argument types of the op. Default to 0 arguments.
list<LLVMType> arguments = [];
// List of valid overload types predicated by DXIL version
- list<VersionedOverloads> overloads;
+ list<Overloads> overloads;
// List of valid shader stages predicated by DXIL version
- list<VersionedStages> stages;
+ list<Stages> stages;
// List of valid attributes predicated by DXIL version
- list<VersionedAttributes> versioned_attributes = [];
+ list<Attributes> attributes = [];
}
Version Specification
@@ -233,7 +233,7 @@ overloads predicated on DXIL version as list of records of the following class
.. code-block::
- class VersionedOverloads<Version minver, list<LLVMType> ols> {
+ class Overloads<Version minver, list<LLVMType> ols> {
Version dxil_version = minver;
list<LLVMType> overload_types = ols;
}
@@ -244,8 +244,8 @@ Following is an example specification of valid overload types for ``DXIL1_0`` an
.. code-block::
overloads = [
- VersionedOverloads<DXIL1_0, [halfTy, floatTy]>,
- VersionedOverloads<DXIL1_2, [halfTy, floatTy, doubleTy]>
+ Overloads<DXIL1_0, [halfTy, floatTy]>,
+ Overloads<DXIL1_2, [halfTy, floatTy, doubleTy]>
];
An empty list signifies that the operation supports no overload types.
@@ -259,7 +259,7 @@ stages predicated on DXIL version as list of records of the following class
.. code-block::
- class VersionedStages<Version minver, list<DXILShaderStage> sts> {
+ class Stages<Version minver, list<DXILShaderStage> sts> {
Version dxil_version = minver;
list<DXILShaderStage> shader_stages = sts;
}
@@ -270,10 +270,10 @@ Following is an example specification of valid stages for ``DXIL1_0``,
.. code-block::
stages = [
- VersionedStages<DXIL1_0, [compute, pixel]>,
- VersionedStages<DXIL1_2, [compute, pixel, mesh]>,
- VersionedStages<DXIL1_4, [all_stages]>,
- VersionedStages<DXIL1_6, [removed]>
+ Stages<DXIL1_0, [compute, pixel]>,
+ Stages<DXIL1_2, [compute, pixel, mesh]>,
+ Stages<DXIL1_4, [all_stages]>,
+ Stages<DXIL1_6, [removed]>
];
The following two pseudo stage records in addition to standard shader stages
@@ -289,7 +289,7 @@ is supported in all DXIL versions and all stages it is required to be specified
.. code-block::
- stages = [VersionedStages<DXIL1_0, [all_stages]>];
+ stages = [Stages<DXIL1_0, [all_stages]>];
Attribute Specification
@@ -300,7 +300,7 @@ attributes predicated on DXIL version as list of records of the following class
.. code-block::
- class VersionedAttributes<MinVersion minver, list<DXILAttribute> attrs> {
+ class Attributes<MinVersion minver, list<DXILAttribute> attrs> {
MinVersion dxil_version = ver;
list<DXILAttribute> attributes = attrs;
}
@@ -309,7 +309,7 @@ Following is an example specification of valid attributes for ``DXIL1_0``.
.. code-block::
- attributes = [VersionedAttributes<DXIL1_0, [ReadNone]];
+ attributes = [Attributes<DXIL1_0, [ReadNone]];
A null list of ``attributes`` signifies no operation attributes.
@@ -326,8 +326,8 @@ For example, consider the following specification of valid overload types:
.. code-block::
overloads = [
- VersionedOverloads<DXIL1_0, [halfTy, floatTy]>,
- VersionedOverloads<DXIL1_2, [halfTy, floatTy, doubleTy]>
+ Overloads<DXIL1_0, [halfTy, floatTy]>,
+ Overloads<DXIL1_2, [halfTy, floatTy, doubleTy]>
];
It specifies that the overload types ``halfTy`` and ``floatTy`` are valid for DXIL
@@ -353,9 +353,9 @@ and has valid overload types predicated on DXIL version.
let LLVMIntrinsic = int_sin;
let result = overloadTy;
let arguments = [overloadTy];
- let overloads = [VersionedOverloads<DXIL1_0, [halfTy, floatTy]>];
- let stages = [VersionedStages<DXIL1_0, [all_stages]>];
- let attributes = [VersionedAttributes<DXIL1_0, [ReadNone]>];
+ let overloads = [Overloads<DXIL1_0, [halfTy, floatTy]>];
+ let stages = [Stages<DXIL1_0, [all_stages]>];
+ let attributes = [Attributes<DXIL1_0, [ReadNone]>];
}
``FlattenedThreadIdInGroup`` - an operation with no arguments, no
@@ -368,8 +368,8 @@ overload types, and valid stages and attributes predicated by DXIL Version.
"group (SV_GroupIndex)";
let LLVMIntrinsic = int_dx_flattened_thread_id_in_group;
let result = i32Ty;
- let stages = [VersionedStages<DXIL1_0, [compute, mesh, amplification, node]>];
- let attributes = [VersionedAttributes<DXIL1_0, [ReadNone]>];
+ let stages = [Stages<DXIL1_0, [compute, mesh, amplification, node]>];
+ let attributes = [Attributes<DXIL1_0, [ReadNone]>];
}
``RawBufferStore`` - an operation with ``void`` return type, valid overload types
@@ -383,12 +383,12 @@ predicated by DXIL Version and valid in all DXIL versions and stages.
let arguments = [dxil_resource_ty, i32Ty, i32Ty, overloadTy,
overloadTy, overloadTy, overloadTy, i8Ty, i32Ty];
let overloads = [
- VersionedOverloads<DXIL1_2, [halfTy, floatTy, i16Ty, i32Ty]>,
- VersionedOverloads<DXIL1_3>,[halfTy, floatTy, doubleTy,
+ Overloads<DXIL1_2, [halfTy, floatTy, i16Ty, i32Ty]>,
+ Overloads<DXIL1_3>,[halfTy, floatTy, doubleTy,
i16Ty, i32Ty, i64Ty]>
];
- let stages = [VersionedStages<DXIL1_2, all_stages>];
- let attributes = [VersionedAttributes<DXIL1_0, [ReadOnly]>];
+ let stages = [Stages<DXIL1_2, all_stages>];
+ let attributes = [Attributes<DXIL1_0, [ReadOnly]>];
}
``DerivCoarseX`` - an operation with no overload types and stages predicated
@@ -402,10 +402,10 @@ by DXIL Version.
let result = overloadTy;
let arguments = [overloadTy];
let stages = [
- Versioned<DXIL1_0, [library, pixel]>,
- Versioned<DXIL1_6, [library, pixel, amplification, compute, mesh]>
+ Stages<DXIL1_0, [library, pixel]>,
+ Stages<DXIL1_6, [library, pixel, amplification, compute, mesh]>
];
- let attributes = [VersionedAttributes<DXIL1_0, [ReadNone]>];
+ let attributes = [Attributes<DXIL1_0, [ReadNone]>];
}
``CreateHandle`` - an operation with no overload types, no associated ``LLVMIntrinsic``
@@ -418,10 +418,10 @@ and stages predicated by DXIL Version.
let result = i32Ty;
let arguments = [i8Ty, i32Ty, i32Ty, i1Ty];
let stages = [
- Versioned<DXIL1_0, [all_stages]>,
- Versioned<DXIL1_6, [removed]
+ Stages<DXIL1_0, [all_stages]>,
+ Stages<DXIL1_6, [removed]
];
- let attributes = [VersionedAttributes<DXIL1_0, [ReadOnly]>];
+ let attributes = [Attributes<DXIL1_0, [ReadOnly]>];
}
``Sample`` - an operation with valid overload types, stages and attributes
@@ -435,12 +435,12 @@ predicated by DXIL version.
let result = resRetF32Ty;
let arguments = [handleTy, handleTy, floatTy, floatTy, floatTy, floatTy,
i32Ty, i32Ty, i32Ty, floatTy];
- let overloads = [Versioned<DXIL1_0, [halfTy, floatTy, i16Ty, i32Ty]>];
+ let overloads = [Overloads<DXIL1_0, [halfTy, floatTy, i16Ty, i32Ty]>];
let stages = [
- Versioned<DXIL1_0, [library, pixel]>,
- Versioned<DXIL1_6, [library, pixel, amplification, compute, mesh]>
+ Stages<DXIL1_0, [library, pixel]>,
+ Stages<DXIL1_6, [library, pixel, amplification, compute, mesh]>
];
- let attributes = [VersionedAttributes<DXIL1_0, [ReadOnly]>];
+ let attributes = [Attributes<DXIL1_0, [ReadOnly]>];
}
Summary
>From 86457cb5486c5a507268fb6e72e4b3e989e59b6b Mon Sep 17 00:00:00 2001
From: Bharadwaj Yadavalli <Bharadwaj.Yadavalli at microsoft.com>
Date: Mon, 22 Jul 2024 16:15:03 -0400
Subject: [PATCH 7/7] Replace usage of the term - constraint.
---
llvm/docs/DirectX/DXILOpTableGenDesign.rst | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/llvm/docs/DirectX/DXILOpTableGenDesign.rst b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
index fca81117e9870..50d801bd05efd 100644
--- a/llvm/docs/DirectX/DXILOpTableGenDesign.rst
+++ b/llvm/docs/DirectX/DXILOpTableGenDesign.rst
@@ -218,12 +218,12 @@ Various operation memory access and boolean attributes such as ``ReadNone``,
def IsWave : DXILOpAttributes;
...
-Constrained Specification
-=========================
+Versioned Property Specification
+================================
DXIL Operation properties such as valid overload types, shader stages and
attributes are predicated on DXIL version. These are represented as list of
-versioned constraints.
+versioned properties.
Overload Type Specification
---------------------------
@@ -313,12 +313,12 @@ Following is an example specification of valid attributes for ``DXIL1_0``.
A null list of ``attributes`` signifies no operation attributes.
-Interpretation of Multiple Constraint Specification
----------------------------------------------------
+Interpretation of Multiple Versioned Properties
+-----------------------------------------------
-Each of the constraints states that the specified overload type, stage or
+Each of the versioned properties states that the specified overload type, stage or
attribute records are valid for the predicated DXIL version. Only
-the constraints corresponding to latest minimal DXIL version is applicable.
+the properties corresponding to latest minimal DXIL version are applicable.
Note as in the above example, any overload types, stages or attributes,
that remain valid in a later DXIL version need to be specified in full.
For example, consider the following specification of valid overload types:
@@ -334,8 +334,8 @@ It specifies that the overload types ``halfTy`` and ``floatTy`` are valid for DX
version 1.0 and later. It also specifies that ``doubleTy`` is additionally supported
in DXIL version 1.2 and later.
-This provides the flexibility to specify constraints independent
-of others in the list.
+This provides the flexibility to specify properties independent of other
+versioned specifications in the list.
DXIL Operation Specification Examples
More information about the llvm-commits
mailing list