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
This introduces an anonymous class "OpLowerer" to help with lowering DXIL ops,
and moves the DXILOpBuilder there instead of creating a new one for every
operation. DXILOpBuilder is also changed to own its IRBuilder, since that makes
it simpler to ensure that it isn't misused.
Pull Request: https://github.com/llvm/llvm-project/pull/104248
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
DXIL operations that only have one signature behave one of two ways - either
they are always suffixed with a type like `dx.op.ThreadId.i32` and hence have
exactly one overload, or they're never suffixed like `dx.op.CreateHandle` and
hence have zero overloads.
Update DXIL.td for operations that have one overload and remove the hack in the
builder that was adjusting names for unoverloaded ops.
Pull Request: https://github.com/llvm/llvm-project/pull/104246
In 8cf85653b6f5 "[DirectX] Make DXILOpBuilder's API more useable" we introduced
specialized createOp methods for each DirectX op for convenience, but the API
is buggy and untested. It also isn't actually as useful as I imagined it would
be since we don't have argument names or const-ness represented in DXIL.td
currently. Remove these methods for now and we can reintroduce them if we
actually need them later.
Pull Request: https://github.com/llvm/llvm-project/pull/104245
This adjusts the DXILOpBuilder API in a couple of ways:
1. Remove the need to call `getOverloadTy` before creating Ops
2. Introduce `tryCreateOp` to parallel `createOp` but propagate errors
3. Introduce specialized createOp methods for each DXIL Op
This will simplify usage of the builder in upcoming changes, and also allows us
to propagate errors via DiagnosticInfo rather than using fatal errors.
Pull Request: https://github.com/llvm/llvm-project/pull/101250
Update TableGen specification of DXIL Op records in DXIL.td per the
current design document.
- Facilitate specification of overloads, shader stage and attributes
predicated on DXIL Ops predicated DXIL version.
Implement functionality to consume in TableGen backend, DXILEmitter, the
above specification enhancements, and generate C++ code (in
(DXILOperations.inc) that represents properties of DXIL Ops, associated
type declarations and corresponding accessor functions.
Changes to DXIL Op Lowering pass to consume the DXIL Op representation
generated by the TableGen back end.
Add mtriple with the required shader model version to commandline of
tests.
Completes #83626
- `CGBuiltin.cpp` - modify `getDotProductIntrinsic` to be able to emit
`dot2`, `dot3`, and `dot4` intrinsics based on element count
- `IntrinsicsDirectX.td` - for floating point add `dot2`, `dot3`, and
`dot4` inntrinsics -`DXIL.td` add dxilop intrinsic lowering for `dot2`,
`dot3`, & `dot4`.
- `DXILOpLowering.cpp` - add vector arg flattening for dot product.
- `DXILOpBuilder.h` - modify `createDXILOpCall` to take a smallVector
instead of an iterator
- `DXILOpBuilder.cpp` - modify `createDXILOpCall` by moving the small
vector up to the calling function in `DXILOpLowering.cpp`.
- Moving one function up gives us access to the `CallInst` and
`Function` which were needed to distinguish the dot product intrinsics
and get the operands without using the iterator.
These all-caps names differ from the llvm naming conventions for no good
reason, and `VOID` in all caps can cause problems in windows
environments (see [1]). Rename them to UpperCamelCase.
[1]: https://github.com/clangd/clangd/issues/1983
Return type of DXIL Ops may be different from valid overload type of the
parameters, if any. Such DXIL Ops are correctly represented in DXIL.td.
However, DXILEmitter assumes the return type to be the same as parameter
overload type, if one exists. This results in generation in incorrect
overload index value in DXILOperation.inc for the DXIL Op and incorrect
DXIL operation function call in DXILOpLowering pass.
This change distinguishes return types correctly from parameter overload
types in DXILEmitter backend to handle such DXIL ops.
Add specification for DXIL Op `isinf` and corresponding tests to verify
the above change.
Fixes issue #85125
Implement an abstraction to specify precise overload types supported by
DXIL ops. These overload types are typically a subset of LLVM
intrinsics.
Implement the corresponding changes in DXILEmitter backend.
Add tests to verify expected errors for unsupported overload types at
code generation time.
Add tests to check for correct overload error output.
* Leverage TableGen record descriptions of LLVM or DirectX intrinsics
that can be directly mapped in DXIL Ops TableGen description. As a
result, such DXIL Ops can be succinctly described without duplication.
DXILEmitter backend can derive the properties of DXIL Ops accordingly.
* Ensured that corresponding lit tests pass.
We have namespaces `DXIL` and `dxil`, which is just confusing. This
renames `DXIL` -> `dxil` making everything consistent.
While the LLVM coding standards don't have a clear direction here, I
chose lower case because by my current unscientific count there are
more places where we had the lowercase namespace than the uppercase.
A new helper class DXILOpBuilder is added to create DXIL op function calls.
TableGen backend for DXILOperation will create table for DXIL op function parameter types.
When create DXIL op function, these parameter types will used to create the function type.
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D130291
