You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NFC: Infrastructure changes for DXIL op vector and multi-dim overloads (microsoft#7259)
This change adds vector and multi-dimensional overload support for DXIL operations. Multi-dimensional (or "extended") overloads are added, where two or more types in a DXIL Op function signature may vary independently, such as both the return type and a parameter type. Until now, only one overload dimension has been necessary. For single-dim overloads, any number of parameters in a DXIL op may refer to this single overload type. For multi-dim overloads, each type that can vary must have a unique overload dimension, even when two or more types must be the same. This follows a pattern from llvm intrinsics. If two or more of the types need to be the same, this constraint must be handled manually, outside the automatic overload constraints defined by the DXIL op definitions. Vector overloads are also added, requiring an additional set of scalar overload types to define the allowed vector element types, on top of the original set describing the allowed scalar overloads for an operation, since both scalar and vector overloads may be allowed on the same operation. There are several components involved in handling DXIL operation overloads, with some changes: - DXIL Op definitions in `hctdb.py` use a string of characters to define the allowed overloads, and special type names used in parameter definitions that refer to the overload type. - Overload string syntax updated and more heavily validated. - `','` may separate dimensions for multi-dim overloads - `'<'` indicates that a vector overload is allowed, in which case, scalar components on the left indicate normal scalar overloads allowed, and scalar components on the right indicate the allowed vector element overloads. - If scalar overloads are present to the left, and omitted to the right, the scalar components are replicated to the right automatically. For instance: `"hf<"` is equivalent to `"hf<hf"`. - `dxil_max_overload_dims = 2` is introduced to define the maximum number of overload dimensions currently supported. - This is used to generate the `DXIL::kDxilMaxOloadDims` definition in `DxilConstants.h`. - `"$x0"` and `"$x1"` are used to reference each overloaded dxil type in parameter definitions when more than one overload dimension is defined for a DXIL op. Other special overload types are not allowed for multi-dim overloads, which means you cannot (currently) describe a multi-dim overload where a returned overload type is wrapped in a resource return struct along with residency status. This could be changed in the future if necessary. - Enforced rules for multi-dim overloads keep them compatible with the llvm intrinsic overloading scheme. - `hctdb_instrhelp.py` translates overload and param type info from DXIL operation definitions into code inserted into `DxilOperations.cpp`. - `DxilOperations.h|cpp` encodes allowed overloads inside `OpCodeProperty` state for each operation in the `m_OpCodeProps` table. It uses this information, along with generated code, to enforce overload rules on DXIL ops. - The allowed overload definition in `OpCodeProperty` has been rewritten to use a more compact `OverloadMask` type, support multi-dim overloads, and add a second layer `AllowedVectorElements` for vector overloads for each dimension. - There are assumptions that one `llvm::Type*` describes the overload type, such as with: `GetOpFunc`, `GetOpFuncList`, `GetOverloadType`, `IsOverloadLegal`, and `m_OpCodeClassCache`. The scheme used for multi-dim overloads is to encode each of the overload types in a single unnamed `StructType`, like `type {i32, <4 x float>}`. This makes it compatible with all these existing mechanisms without requiring an API overhaul impacting the broader code base. `GetExtendedOverloadType` is used to construct this type from multiple types. While updating `DxilOperations.h|cpp`, I noticed and removed some unused methods: `IsDxilOpTypeName`, `IsDxilOpType`, `IsDupDxilOpType`, `GetOriginalDxilOpType`. --------- Co-authored-by: Greg Roth <grroth@microsoft.com>
0 commit comments