- The DXIL data scalarizer only needs to change vectors into arrays. It
does not need to change the types of GEPs to match the pointer type.
This PR simplifies the `visitGetElementPtrInst` method to do just that
while also accounting for nested GEPs from ConstantExprs. (Before this
PR, there were still vector types lingering in nested GEPs with
ConstantExprs.)
- The `equivalentArrayTypeFromVector` function was awkwardly placed near
the top of the file and away from the other helper functions. The
function is now moved next to the other helper functions.
- Removed an unnecessary `||` condition from `isVectorOrArrayOfVectors`
Related tests have also been cleaned up, and the test CHECKs have been
modified to account for the new simplified behavior.
This PR adds a Load method for resources, which takes an additional
parameter by reference, status. It fills the status parameter with a 1
or 0, depending on whether or not the resource access was mapped.
CheckAccessFullyMapped is also added as an intrinsic, and called in the
production of this status bit.
Only addresses DXIL for the below issue:
https://github.com/llvm/llvm-project/issues/138910
Also only addresses the DXIL variant for the below issue:
https://github.com/llvm/llvm-project/issues/99204
Currently LibcallLoweringInfo is defined inside of TargetLowering,
which is owned by the subtarget. Pass in the subtarget so we can
construct LibcallLoweringInfo with the subtarget. This is a temporary
step that should be revertable in the future, after LibcallLoweringInfo
is moved out of TargetLowering.
This change drops the use of the "Layout" type and instead uses explicit
padding throughout the compiler to represent types in HLSL buffers.
There are a few parts to this, though it's difficult to split them up as
they're very interdependent:
1. Refactor HLSLBufferLayoutBuilder to allow us to calculate the padding
of arbitrary types.
2. Teach Clang CodeGen to use HLSL specific paths for cbuffers when
generating aggregate copies, array accesses, and structure accesses.
3. Simplify DXILCBufferAccesses such that it directly replaces accesses
with dx.resource.getpointer rather than recalculating the layout.
4. Basic infrastructure for SPIR-V handling, but the implementation
itself will need work in follow ups.
Fixes several issues, including #138996, #144573, and #156084.
Resolves#147352.
In #163587 we attempted to generate a dxc-compatible DataLayout when
emitting DXIL, but somehow got it wrong. Update using the DataLayout
that dxc emits verbatim.
Fixes#163882
Both conceptually belong to the same subtarget, so it should not
be necessary to pass in the context TargetRegisterInfo to any
TargetInstrInfo member. Add this reference so those superfluous
arguments can be removed.
Most targets placed their TargetRegisterInfo as a member
in TargetInstrInfo. A few had this owned by the TargetSubtargetInfo,
so unify all targets to look the same.
This isn't reachable today but will come into play once we reorder
passes for #147352 and #147351.
Note that the `CBufferRowIntrin` helper struct is copied from the
`DXILCBufferAccess` pass, but it will be removed from there when we
simplify that pass in #147351
fixes#165051
This change reverts the experiment we did for #165311
While some backends seem to support llvm.assume without validation The
validator itself does not so it makes more sense to just remove it.
This pr lets the `dxil-data-scalarization` account for a GEP with a
source type that is a sub-type of the pointer operand type.
The pass is updated so that the replaced GEP introduces zero indices
such that the result type remains the same (with the vector -> array
transform).
Please see resolved issue for an annotated example.
Resolves: https://github.com/llvm/llvm-project/issues/165473
This pr adds support for emitting the `hlsl.wavesize` function attribute
as an entry property metadata for a compute shader.
It follows the implementation of `hlsl.numthreads`.
- Collects the wave range information from the function attribute in
`DXILMetadataAnalysis`
- Introduce the `WaveRange` property tag
- Emit a `WaveSize` or `WaveRange` metadata (depending on shader model)
in `DXILTranslateMetadata`
- Add tests for valid/invalid scenarios
- Updates the base `PSVInfo` to reflect the min/max wave lane counts
Resolves#70118
Implement the f16tof32() intrinsic, including DXILand SPIRV codegen, and
associated tests.
Fixes#99112
---------
Co-authored-by: Tim Corringham <tcorring@amd.com>
This PR fixes the appearance of the following warning message when
building LLVM with clang (21.1.2)
```
[48/100] Building CXX object lib/Target/DirectX/CMakeFiles/LLVMDirectXCodeGen.dir/DXContainerGlobals.cpp.o
In file included from /nix/store/ffrg0560kj0066s4k9pznjand907nlnz-gcc-14.3.0/include/c++/14.3.0/cassert:44,
from /workspace/llvm-project/llvm/include/llvm/Support/Endian.h:19,
from /workspace/llvm-project/llvm/include/llvm/Support/MD5.h:33,
from /workspace/llvm-project/llvm/lib/Target/DirectX/DXContainerGlobals.cpp:28:
/workspace/llvm-project/llvm/lib/Target/DirectX/DXContainerGlobals.cpp: In lambda function:
/workspace/llvm-project/llvm/lib/Target/DirectX/DXContainerGlobals.cpp:198:78: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
198 | (uint64_t)Binding.LowerBound + Binding.Size - 1 <= UINT32_MAX &&
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
199 | "Resource range is too large");
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
I marked this PR as an NFC because it only modifies an assertion condition to remove a compiler warning.
This pr introduces an allow-list for module metadata, this encompasses
the llvm metadata nodes: `llvm.ident` and `llvm.module.flags`, as well
as, the generated `dx.` options.
Resolves: #164473.
This pr adds the equivalent validation of `llvm.loop` metadata that is
[done in
DXC](8f21027f2a/lib/DxilValidation/DxilValidation.cpp (L3010)).
This is done as follows:
- Add `llvm.loop` to the metadata allow-list in `DXILTranslateMetadata`
- Iterate through all `llvm.loop` metadata nodes and strip all
incompatible ones
- Raise an error for ill-formed nodes that are compatible with DXIL
Resolves: https://github.com/llvm/llvm-project/issues/137387
Adds the WaveActiveMin intrinsic from #99169. I think I did all of the
required things on the checklist:
- [x] Implement `WaveActiveMin` clang builtin,
- [x] Link `WaveActiveMin` clang builtin with `hlsl_intrinsics.h`
- [x] Add sema checks for `WaveActiveMin` to
`CheckHLSLBuiltinFunctionCall` in `SemaChecking.cpp`
- [x] Add codegen for `WaveActiveMin` to `EmitHLSLBuiltinExpr` in
`CGBuiltin.cpp`
- [x] Add codegen tests to
`clang/test/CodeGenHLSL/builtins/WaveActiveMin.hlsl`
- [x] Add sema tests to
`clang/test/SemaHLSL/BuiltIns/WaveActiveMin-errors.hlsl`
- [x] Create the `int_dx_WaveActiveMin` intrinsic in
`IntrinsicsDirectX.td`
- [x] Create the `DXILOpMapping` of `int_dx_WaveActiveMin` to `119` in
`DXIL.td`
- [x] Create the `WaveActiveMin.ll` and `WaveActiveMin_errors.ll` tests
in `llvm/test/CodeGen/DirectX/`
- [x] Create the `int_spv_WaveActiveMin` intrinsic in
`IntrinsicsSPIRV.td`
- [x] In SPIRVInstructionSelector.cpp create the `WaveActiveMin`
lowering and map it to `int_spv_WaveActiveMin` in
`SPIRVInstructionSelector::selectIntrinsic`.
- [x] Create SPIR-V backend test case in
`llvm/test/CodeGen/SPIRV/hlsl-intrinsics/WaveActiveMin.ll
But as some of the code has changed and was moved around (E.G.
`CGBuiltin.cpp` -> `CGHLSLBuiltins.cpp`) I mostly followed how
`WaveActiveMax()` is implemented.
I have not been able to run the tests myself as I am unsure which
project runs the correct test. Any guidance on how I can test myself
would be helpful.
Also added some tests to the offload-test-suite
https://github.com/llvm/offload-test-suite/pull/478
fixes#165051
Change is just to let the assume intrinsic pass on unmodified. Test is
to confirm the DXIL disassembler doesn't blow up whe we generate DXIL
with this intrinsic.
In DXIL, some 64bit types are actually represented with their 32bit
counterpart. This was already being address in the codegen, however the
metadata generation was lacking this information. This PR is fixing this
issue.
Closes: [#146735](https://github.com/llvm/llvm-project/issues/146735)
This pr updates `DXILPrepare` and `DXILTranslateMetadata` by moving all
the removal of metadata from `DXILPrepare` to `DXILTranslateMetadata` to
have a more consistent definition of what each pass is doing.
It restricts the `DXILPrepare` to only update function attributes and
insert bitcasts, and moves the removal of metadata to
`DXILTranslateMetadata` so that all manipulation of metadata is done in
a single pass.
This is a temporary measure to explicitly remove the unrecognized named
metadata when targeting DXIL.
This should be removed for an allowlist as tracked here:
https://github.com/llvm/llvm-project/issues/164473.
Introduces LLVM intrinsic `llvm.dx.resource.getdimensions.x` and its lowering to DXIL op `op.dx.getDimensions`.
The intrinsic will be used to implement `GetDimension` for buffers. The lowering is using `undef` value since it is required by the DXIL format which is based on LLVM 3.7.
Proposal update: https://github.com/llvm/wg-hlsl/pull/350Closes#112982
Move our handling of setting up a compatible triple for DXIL to the
bitcode writer itself, and do the same for the datalayout. This avoids
us needing to temporarily change the triple just to change it back, and
it also allows us to make the datalayout truly compatible, including the
`i8:32` alignment that isn't accepted by modern LLVM's DataLayout.
When calculating the upper bound for resource binding to be stored in the PSV0 part of the DXIL container, the compiler needs to take into account that the resource range could be _unbounded_, which is indicated by the binding size being `UINT32_MAX`.
Fixes [#159679](https://github.com/llvm/llvm-project/issues/159679)
Root Signature Flags, allow flags to block compilation of certain shader
stages. This PR implements a validation and notify the user if they
compile a root signature that is denying such shader stage.
Closes: https://github.com/llvm/llvm-project/issues/153062
Previously approved: https://github.com/llvm/llvm-project/pull/153287
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
Co-authored-by: Joao Saffran <{ID}+{username}@users.noreply.github.com>
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
Introduces `llvm.{dx|svp}.resource.nonuniformindex` intrinsic that will be used when a resource index is not guaranteed to be uniform across threads (HLSL function NonUniformResourceIndex).
The DXIL lowering layer looks for this intrinsic call in the resource index calculation, makes sure it is reflected in the NonUniform flag on DXIL create handle ops (`dx.op.createHandle` and `dx.op.createHandleFromBinding`), and then removes it from the module.
Closes#155701
MC Static Samplers Representation currently depends on Object
structures. This PR removes that dependency and in order to facilitate
removing to_underlying usage in follow-up PRs.
Clang and other frontends generally need the LLVM data layout string in
order to generate LLVM IR modules for LLVM. MLIR clients often need it
as well, since MLIR users often lower to LLVM IR.
Before this change, the LLVM datalayout string was computed in the
LLVM${TGT}CodeGen library in the relevant TargetMachine subclass.
However, none of the logic for computing the data layout string requires
any details of code generation. Clients who want to avoid duplicating
this information were forced to link in LLVMCodeGen and all registered
targets, leading to bloated binaries. This happened in PR #145899,
which measurably increased binary size for some of our users.
By moving this information to the TargetParser library, we
can delete the duplicate datalayout strings in Clang, and retain the
ability to generate IR for unregistered targets.
This is intended to be a very mechanical LLVM-only change, but there is
an immediately obvious follow-up to clang, which will be prepared
separately.
The vast majority of data layouts are computable with two inputs: the
triple and the "ABI name". There is only one exception, NVPTX, which has
a cl::opt to enable short device pointers. I invented a "shortptr" ABI
name to pass this option through the target independent interface.
Everything else fits. Mips is a bit awkward because it uses a special
MipsABIInfo abstraction, which includes members with codegen-like
concepts like ABI physical registers that can't live in TargetParser. I
think the string logic of looking for "n32" "n64" etc is reasonable to
duplicate. We have plenty of other minor duplication to preserve
layering.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
MC Descriptor Range Representation currently depend on Object
structures. This PR removes that dependency and in order to facilitate
removing to_underlying usage in follow-up PRs.
This pr implements support for a root signature as a target, as specified
[here](https://github.com/llvm/wg-hlsl/blob/main/proposals/0029-root-signature-driver-options.md#target-root-signature-version).
This is implemented in the following steps:
1. Add `rootsignature` as a shader model environment type and define
`rootsig` as a `target_profile`. Only valid as versions 1.0 and 1.1
2. Updates `HLSLFrontendAction` to invoke a special handling of
constructing the `ASTContext` if we are considering an `hlsl` file and
with a `rootsignature` target
3. Defines the special handling to minimally instantiate the `Parser`
and `Sema` to insert the `RootSignatureDecl`
4. Updates `CGHLSLRuntime` to emit the constructed root signature decl
as part of `dx.rootsignatures` with a `null` entry function
5. Updates `DXILRootSignature` to handle emitting a root signature
without an entry function
6. Updates `ToolChains/HLSL` to invoke `only-section=RTS0` to strip any
other generated information
Resolves: https://github.com/llvm/llvm-project/issues/150286.
##### Implementation Considerations
Ideally we could invoke this as part of `clang-dxc` without the need of
a source file. However, the initialization of the `Parser` and `Lexer`
becomes quite complicated to handle this.
Technically, we could avoid generating any of the extra information that
is removed in step 6. However, it seems better to re-use the logic in
`llvm-objcopy` without any need for additional custom logic in
`DXILRootSignature`.
This will make it possible for tablegen to make subtarget
dependent decisions without adding new arguments to every
target.
---------
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
fixes#156068
- We needed to add a new sub arch to the target tripple so we can test
that emulation does not happen when targeting SM6.9
- The HLSL toolchain needed to be updated to handle the conversion of
strings to enums for the new sub arch.
- The emulation is done in DXILIntrinsicExpansion.cpp and needs to be
able to convert both llvm.is.fpclass and lvm.dx.isinf to the proper
emulation
- test updates in TargetParser/TripleTest.cpp, isinf.ll, is_fpclass.ll,
and DXCModeTest.cpp
fixes#152348
SimplifyCFG collapses raw buffer store from a if\else load into a
select.
This change prevents the TargetExtType dx.Rawbuffer from being replace
thus preserving the if\else blocks.
A further change was needed to eliminate the phi node before we process
Intrinsic::dx_resource_getpointer in DXILResourceAccess.cpp
DXC checks if registers are correctly bound to root signature
descriptors. This implements the same check.
closes: #[126645](https://github.com/llvm/llvm-project/issues/126645)
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
Removes uniformity bit from resource initialization intrinsics `llvm.{dx|spv}.resource.handlefrombinding` and `llvm.{dx|spv}.resource.handlefromimplicitbinding`. The flag currently always set to `false`. It should be derived from resource analysis and not provided by codegen.
Closes#135452
Add `BinaryFormat` to `LINK_COMPONENTS` to fix the following linker
error:
```
ld.lld: error: undefined symbol: llvm::dxbc::getRootParameterTypes()
>>> referenced by DXILRootSignature.cpp
>>> lib/Target/DirectX/CMakeFiles/LLVMDirectXCodeGen.dir/DXILRootSignature.cpp.o:(llvm::dxil::RootSignatureAnalysisPrinter::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&))
ld.lld: error: undefined symbol: llvm::dxbc::getShaderVisibility()
>>> referenced by DXILRootSignature.cpp
>>> lib/Target/DirectX/CMakeFiles/LLVMDirectXCodeGen.dir/DXILRootSignature.cpp.o:(llvm::dxil::RootSignatureAnalysisPrinter::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&))
>>> referenced by DXILRootSignature.cpp
>>> lib/Target/DirectX/CMakeFiles/LLVMDirectXCodeGen.dir/DXILRootSignature.cpp.o:(llvm::dxil::RootSignatureAnalysisPrinter::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&))
```
Root cause: https://github.com/llvm/llvm-project/pull/154249 changed a
header-only dependency to a real dependency without noticing that the
dependency was missing in CMakeLists.txt
Fixes#153304
Changes:
- When writing `ConstantExpr` GEPs to DXIL bitcode, the bitcode writer
will use the old Constant Code `CST_CODE_CE_GEP_OLD = 12` instead of the
newer `CST_CODE_CE_GEP = 32` which is interpreted as an undef in DXIL.
Additional context: [CST_CODE_CE_GEP = 12 in
DXC](0c9e75e7e9/include/llvm/Bitcode/LLVMBitCodes.h (L187))
while the same constant code is labeled [CST_CODE_CE_GEP_OLD in
LLVM](65de318d18/llvm/include/llvm/Bitcode/LLVMBitCodes.h (L411))
- Modifies the `PointerTypeAnalysis` to be able to analyze pointer-typed
constants that appear in the operands of instructions so that the
correct type of the `ConstantExpr` GEP is determined and written into
the DXIL bitcode.
- Adds a `PointerTypeAnalysis` test and dxil-dis test to ensure that the
pointer type of `ConstantExpr` GEPs are resolved and `ConstantExpr` GEPs
are written to DXIL bitcode correctly
In addition, this PR also adds a missing call to
`GV.removeDeadConstantUsers()` in the DXILFinalizeLinkage pass, and
removes an unnecessary manual removal of a ConstantExpr in the
DXILFlattenArrays pass.
This patch is refactoring Root Parameter Header in DX Container backend
to remove the usage of `to_underlying`. This requires some changes:
first, MC Root Signature should not depend on Object/DXContainer.h;
Second, we need to assume data to be valid in scenarios where it was
originally not expected, this made some tests be removed.
Fixes#139023.
This PR essentially removes unused global variables:
- Restores the `GlobalDCE` Legacy pass and adds it to the DirectX
backend after the finalize linkage pass
- Converts external global variables with no usage to internal linkage
in the finalize linkage pass
- (so they can be removed by `GlobalDCE`)
- Makes the `dxil-finalize-linkage` pass usable using the new pass
manager flag syntax
- Adds tests to `finalize_linkage.ll` that make sure unused global
variables are removed
- Adds a use for variable `@CBV` in `opaque-value_as_metadata.ll` so it
isn't removed
- Changes the `scalar-data.ll` run command to avoid removing its global
variables
---------
Co-authored-by: Farzon Lotfi <farzonlotfi@microsoft.com>
As part of the Root Signature Spec, we need to validate if Root
Signatures are not defining overlapping ranges.
Closes: https://github.com/llvm/llvm-project/issues/126645
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
Co-authored-by: Joao Saffran <{ID}+{username}@users.noreply.github.com>
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
