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
Implement support for HLSL intrinsic saturate.
Implement DXIL codegen for the intrinsic saturate by lowering it to DXIL
Op dx.saturate.
Implement SPIRV codegen by transforming saturate(x) to clamp(x, 0.0f,
1.0f).
Add tests for DXIL and SPIRV CodeGen.
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
All expansions end with replacing the previous inrinsic with the new
expansion and erasing the old one. By moving this operation to the
caller, these expansion functions can be called in more contexts and a
small amount of duplicated code is consolidated.
Pre-req for #88056
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
An HLSL function has internal linkage by default unless it is:
1. shader entry point function
2. marked with the `export` keyword
(https://github.com/llvm/llvm-project/issues/92812)
3. patch constant function (not implemented yet)
This PR adds a link-time pass `DXILFinalizeLinkage` that updates the
linkage of functions to make sure only shader entry points and exported
functions are visible from the module (have _program linkage_). All
other functions will be updated to have internal linkage.
Related spec update: microsoft/hlsl-specs#295
Fixes #llvm/llvm-project#92071
This PR adds the length intrinsic and an HLSL function that uses it.
The SPIRV implementation is left for a future PR.
This PR addresses #99134, though some SPIR-V changes still need to be
made to complete the task. Below is how this PR addresses #99134.
- "Implement `length` clang builtin" was done by defining `HLSLL ength`
in Builtins.td
- "Link `length` clang builtin with hlsl_intrinsics.h" was done by using
the alias attribute to make `length` an alias of
`__builtin_hlsl_elementwise_length` in hlsl_intrinsics.h
- "Add sema checks for `length` to `CheckHLSLBuiltinFunctionCall` in
`SemaChecking.cpp` " was done, but in this case not in SemaChecking.cpp,
rather SemaHLSL.cpp. A case was added to the builtin to check for
semantic failures, and set `TheCall` up to have the right return type.
- "Add codegen for `length` to `EmitHLSLBuiltinExpr` in `CGBuiltin.cpp`"
was done. For scalars, fabs is emitted, otherwise, length is emitted.
- "Add codegen tests to `clang/test/CodeGenHLSL/builtins/length.hlsl`
was done to test that `length` in HLSL emits the right intrinsic.
- "Add sema tests to `clang/test/SemaHLSL/BuiltIns/length-errors.hlsl`"
was done to test for diagnostics emitted in SemaHLSL.cpp
- "Create the `int_dx_length` intrinsic in `IntrinsicsDirectX.td`" was
done. Specifying return types and parameter types was difficult, but
`idot` was used for reference, and `llvm\include\llvm\IR\Intrinsics.td`
contains all the ways to express return / parameter types.
- "Create an intrinsic expansion of `int_dx_length` in
`llvm/lib/Target/DirectX/DXILIntrinsicExpansion.cpp`" was done, and was
mostly derived by looking at `TranslateLength` in `HLOperationLower.cpp`
in the DXC codebase.
- "Create the `length.ll` and `length_errors.ll` tests in
`llvm/test/CodeGen/DirectX/`" was done by taking the DXIL output of
`clang/test/CodeGenHLSL/builtins/length.hlsl` and running `opt -S
-dxil-intrinsic-expansion` and ` opt -S -dxil-op-lower` on it, checking
for how the length intrinsic was either expanded or lowered.
- "Create the `int_spv_length` intrinsic in `IntrinsicsSPIRV.td`" was
done by copying `IntrinsicsDirectX.td`.
---------
Co-authored-by: Justin Bogner <mail@justinbogner.com>
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
These passes will be replaced soon as we move to the target extension based
resource handling in the DirectX backend, but removing them now before the
replacement stuff is all up and running would be very disruptive. However, we
do need to move these passes out of the way to avoid symbol conflicts with the
new DXILResourceAnalysis in the Analysis library.
Note: I tried an even simpler hack in #100698 but it doesn't really work. A
rename is the most expedient path forward here.
Pull Request: https://github.com/llvm/llvm-project/pull/101393
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.
It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.
This _incompatibly_ changes the ABI of any LLVM IR function with
`x86_mmx` arguments or returns: instead of passing in mmx registers,
they will now be passed via integer registers. However, the real-world
incompatibility caused by this is expected to be minimal, because Clang
never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>`
or `double`, depending on ABI.
This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type.
That type simply no longer corresponds to an IR type, and is used only
by MMX intrinsics and inline-asm operands.
Because SelectionDAGBuilder only knows how to generate the
operands/results of intrinsics based on the IR type, it thus now
generates the intrinsics with the type MVT::v1i64, instead of
MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus
have the X86 backend fix them up in DAGCombine. (This may be a
short-lived hack, if all the MMX intrinsics can be removed in upcoming
changes.)
Works towards issue #98272.
For DXIL which is based on llvm 3.7, max supported behavior flag for
module flags is 6.
The commit will check all module flags, for behavior flag > 6, change it
to 2 (Warning).
This is to fix the behavior flag part for #96912.
Direct3D requires a PSV0 section to be present in the DXContainer in
order to be able to load and use the shader.
This change adds a minimal stub PSV0, with some hard-coded values, that
are just enough to unblock loading into Direct3D.
Contributes to #90129
On MSVC the `this` uses inside `decltype` require a lambda capture. On
clang they result in an unused capture warning instead. Add the capture
and suppress the warning with `(void)this`.
-----
Initializing this map is somewhat expensive (especially for O0), so we
currently only do it if certain flags are used. I would like to make use
of it for crash dumps (#96078), where we don't know in advance whether
it will be needed or not.
This patch changes the initialization to a lazy approach, where a
callback is registered that does the actual initialization. The
callbacks will be run the first time the pass name is requested.
This way there is no compile-time impact if the mapping is not used.
My attempt to fix the Windows build made things worse,
revert entirely for now.
This reverts commit e7137f2fed5cfee822ae3c4c6d39188adb59a16c.
This reverts commit 6eaf204dbb0a6a81cddfd02f625c130f7bb1aae5.
This reverts commit 957dc4366dd2ce9d5d2991c3ad76bbf438e9954e.
The icmp and fcmp constant expressions were removed in deab451e7a7f
"[IR] Remove support for icmp and fcmp constant expressions (#93038)".
Update the DXILBitcodeWriter to stop referencing them.
This change is an implementation of #87367's investigation on supporting
IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088
Changes:
- `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
- `llvm/lib/Target/DirectX/DXIL.td` - Map `int_tan` (the tan intrinsic)
to the equivalent DXIL Op.
Remove string function attribute other than
"waveops-include-helper-lanes" and "fp32-denorm-mode".
Move DXILPrepareModulePass after DXILTranslateMetadataPass since
DXILTranslateMetadataPass needs to use attribute like hlsl.numthreads.
Fixes#90773
Removing the intrinsic because there is no opCodes for rcp in DXIL or
SPIR-V.
Moving means we don't have to re-implement this feature for each
backend.
fixes#87784
Co-authored-by: Farzon Lotfi <farzon@farzon.com>
completes #86187
- fix hlsl_intrinsic to cover the correct cases
- move to using `__builtin_elementwise_sqrt`
- add lowering of `Intrinsic::sqrt` to dxilop 24.
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.
PR #86242 introduced a copy-paste error that caused some tests to fail
by mapping the wrong pass name to a pass. This resolves the issue and
fixes the failing tests.
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
This change completes #86155
- `DXIL.td` - lowering `fabs` intrinsic to the float dxil op.
- `DXILIntrinsicExpansion.cpp` - Add intrinsic expansion for the abs
case.
