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 <[email protected]>
0 commit comments