The `@llvm.dx.typedBufferLoad` intrinsic is lowered to `@dx.op.bufferLoad`.
There's some complexity here in translating to scalarized IR, which I've
abstracted out into a function that should be useful for samples, gathers, and
CBuffer loads.
I've also updated the DXILResources.rst docs to match what I'm doing here and
the proposal in llvm/wg-hlsl#59. I've removed the content about stores and raw
buffers for now with the expectation that it will be added along with the work.
Note that this change includes a bit of a hack in how it deals with
`getOverloadKind` for the `dx.ResRet` types - we need to adjust how we deal
with operation overloads to generate a table directly rather than proxy through
the OverloadKind enum, but that's left for a later change here.
Part of #91367
Pull Request: https://github.com/llvm/llvm-project/pull/104252
The `@llvm.dx.handle.fromBinding` intrinsic is lowered either to the
`CreateHandle` op or a pair of `CreateHandleFromBinding` and `AnnotateHandle`
ops, depending on the DXIL version. Regardless of the DXIL version we need to
emit metadata about the binding, but that's left to a separate change.
These DXIL ops all need to return the `%dx.types.Handle` type, but the llvm
intrinsic returns a target extension type. To facilitate changing the type of
the operation and all of its users, we introduce `%llvm.dx.cast.handle`, which
can cast between the two handle representations.
Pull Request: https://github.com/llvm/llvm-project/pull/104251
LLVMType is both too broad and too narrow for defining DXIL operations, in
different ways. It's too broad in the sense that we don't need the full set of
MVTs - the set of types DXIL operations work on is much smaller. It's too
narrow in the sense that it's difficult to use it for the various fixed
structure types in DXIL, like `%dx.types.Handle` or `%dx.Types.ResRet.f32`.
Replace the usage of LLVMType in DXIL.td with DXILOpParamType, a simple class
that we can define an enum of types from. Further, use this to replace the
"ParameterKind" enum in DXILABI.h that has nothing to do with DXIL's ABI.
Pull Request: https://github.com/llvm/llvm-project/pull/104247
This adds a new document about DXIL Resource Handling. I've attempted to
describe here how we intend to use TargetExtTypes to represent resources
in LLVM IR and the various intrinsics we'll need to lower these through
LLVM to DXIL.
For now this document is limited to the high level concepts and a few
details on buffer types, and there are a number of TODOs in the document
that we'll iterate on as we progress in the implementation.
Add a mechanism to specify constraints to the design document. These facilitate
specification of DXIL Op attributes that are predicated by Shader Model version.
This just seeks to give a high level overview of the current state of
the DirectX backend. It doesn't go in too deep, but should be a starting
point for further documentation.
---------
Co-authored-by: S. Bharadwaj Yadavalli <Bharadwaj.Yadavalli@microsoft.com>
This documents some of the architectural direction for DXIL and tries
to provide a bit of a map for where to implement different aspects of
DXIL support.
Pull Request: https://github.com/llvm/llvm-project/pull/78221
