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`.
Update resource type names for globals variables that we generate in `DXILTranslateMetadata` pass to include element type. This change prevents duplicate types for identical resources and brings the DXIL metadata names it closer to what DXC generates.
Moving `DXILResourceImplicitBinding` pass and the associated `DXILResourceBindingAnalysis` lower in the llc pipeline to just before the DXIL Resource Analysis, which is where its results are first needed, and adjusting the set of analyses it preserves.
The reason for this change is that I will soon be adding `DXILResourceBindingAnalysis` dependency to `DXILPostOptimizationValidation` pass and bringing this closer to where it is needed avoid unnecessary churn to preserved analysis setting in preceding passes.
This annotates the `Twine` passed to the constructors of the various
DiagnosticInfo subclasses with `[[clang::lifetimebound]]`, which causes
us to warn when we would try to print the twine after it had already
been destructed.
We also update `DiagnosticInfoUnsupported` to hold a `const Twine &`
like all of the other DiagnosticInfo classes, since this warning allows
us to clean up all of the places where it was being used incorrectly.
Removing `DXILResourceMDAnalysis` that gathers information about
resources for the `DXILTranslateMetadata` pass. It collects the info
based on obsolete resource metadata annotations that are going to be
removed soon.
Part 1/2 of #114126
- Adding the changes from PRs:
- #116331
- #121852
- Fixes test `tools/dxil-dis/debug-info.ll`
- Address some missed comments in the previous PR
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
- adding Flatten and Branch to if stmt.
- adding dxil control flow hint metadata generation
- modifing spirv OpSelectMerge to account for the specific attributes.
Closes#70112
---------
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
Move the DXILOpLoweringPass after DXILTranslateMetadata, and add asserts
in DXILShaderFlags to ensure it isn't scheduled after op lowering. This
will allow us to rely on DirectX intrinsics in the shader flags analysis
rather than having to recover information from lowered operations.
Fixes#120119.
We need to create symbols with "the original shape of resource and
element type" to put in the resource metadata in order to generate valid
DXIL.
Note that DXC generally doesn't emit an actual symbol outside of library
shaders (it emits an undef of a pointer to the type), but since we have
to deal with opaque pointers we would need a way to smuggle the type
through to match that. Instead, we simply emit symbols for now.
Fixed#116849
This splits the DXILResourceAnalysis pass into TypeAnalysis and
BindingAnalysis passes. The type analysis pass is made immutable and
populated lazily so that it can be used earlier in the pipeline without
needing to carefully maintain the invariants of the binding analysis.
Fixes#118400
Instead of storing an auxilliary structure with the information from the
DXIL resource target extension types duplicated, access the information
that we can via the type itself.
This also means we need to handle some of the target extension types we
haven't fully defined yet, like Texture and CBuffer. For now we make an
educated guess to what those should look like based on llvm/wg-hlsl#76,
and we can update them fairly easily when we've defined them more
thoroughly.
First part of #118400
Currently, ShaderFlagsAnalysis pass represents various module-level
properties as well as function-level properties of a DXIL Module using a
single mask. However, one mask per function is needed for accurate
computation of shader flags mask, such as for entry function metadata
creation.
This change introduces a structure that wraps a sorted vector of
function-shader flag mask pairs that represent function properties
instead of a single shader flag mask that represents module properties
and properties of all functions. The result type of ShaderFlagsAnalysis
pass is changed to newly-defined structure type instead of a single
shader flags mask.
This allows accurate computation of shader flags of an entry function
(and all functions in a library shader) for use during its metadata
generation (DXILTranslateMetadata pass) and its feature flags in DX
container globals construction (DXContainerGlobals pass) based on the
shader flags mask of functions. However, note that the change to
implement propagation of such callee-based shader flags mask computation
is planned in a follow-on PR. Consequently, this PR changes shader flag
mask computation in DXILTranslateMetadata and DXContainerGlobals passes
to simply be a union of module flags and shader flags of all functions,
thereby retaining the existing effect of using a single shader flag
mask.
- Changed `DXILTranslateMetadata::translateMetadata()` to consume DXIL
Metadata Analysis information. Subsumed into `DXILTranslateMetedata.cpp`
the functionality in `DXILMetadata.*` files - that are hence deleted.
- Changed `DXILPrepare` pass to consume DXIL Metadata Analysis
information.
- Renamed `ModuleMetadataInfo::ShaderStage` to
`ModuleMetadataInfo::ShaderProfile` to better convey what it represents.
- Updated `unknown` target shader stage specification in triples of a
couple of tests.
- Added new tests for additional verification of `DXILTranslateMetadata`
pass functionality.
Replace the hardcoded values for compute shader in
DXContainer::addPipelineStateValidationInfo.
Still missing wave size.
Add preserved for previous passes so the information is not lost.
Fix https://github.com/llvm/wg-hlsl/issues/51
Move the module level logic for resources into the pretty printer and translate
metadata passes rather than embedding them in the DXILResource helper. This
will make it easier to migrate towards the target extension type based approach
to resources.
Pull Request: https://github.com/llvm/llvm-project/pull/104446
This wires up dxil-op-lower, dxil-intrinsic-expansion, dxil-translate-metadata,
and dxil-pretty-printer to the new pass manager, both as a matter of future
proofing the backend and so that they can be used more flexibly in tests.
A few arbitrary tests are updated in order to test the new PM path, and we drop
the "print-dxil-resource-md" pass since it's redundant with the pretty printer.
Pull Request: https://github.com/llvm/llvm-project/pull/104250
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
Add DXIL module flag bit offset for SHADER_FEATURE_FLAG.
Added DXIL_MODULE_FLAG for DXIL module flag which does not have feature flag.
Use DXILModuleFlags for ComputedShaderFlags instead of
ShaderFeatureFlags.
ComputedShaderFlags::getFeatureFlags() was added to get FeatureFlags.
Rename DXContainerGlobals::getShaderFlags to DXContainerGlobals::getFeatureFlags.
Fixes#57925
New named metadata "dx.entryPoints" is added to save all entries.
Each entry is in format of
!{ptr to function, name, signature, resource table, extra}
For compute shader, the extra will save num of threads in format of {i32 x, i32 y, i32 z}
For library profile, an empty entry will be added to save the resource table for the library.
Signature and resource table metadata is not generated yet.
Differential Revision: https://reviews.llvm.org/D131807
Now only DXILTranslateMetadata uses DXILResources, so DXILResourceWrapper is only used by DXILTranslateMetadata.
Once we add lower for createHandle, DXILResourceWrapper will be used in more passes.
Also we can add resource index allocation in DXILResourceWrapper.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D135190
This code adds initial support for generating the HLSL resources
metadata entries. It has a lot of `FIXMEs` laying around because there
is a lot more work to do here, but this lays a solid groundwork and can
accurately handle some trivial cases.
I've filed a swath of issues covering the deficiencies here and left the
issues in comments so that we can easily follow them.
One big change to make sooner rather than later is to move some of this
code into a new libLLVMFrontendHLSL so that we can share it with the
Clang CodeGen layer.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D134682
This captures the target shader model and pipeline stage into the DXIL
metadata for consumption by the DirectX runtime.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D134469
DXIL relies on a whole bunch of IR metadata constructs being populated
in the right shape. Rather than just hard coding or using complicated
arrangements of constant data strings, let's make first-class objects
that reprensent the metadata and manage reading and writing the
metadata from the module.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D134397
Put DXIL validation version into separate NamedMetadata to avoid update ModuleFlags.
Currently DXIL validation version is saved in ModuleFlags in clang codeGen.
Then in DirectX backend, the data will be extracted from ModuleFlags and cause rebuild of ModuleFlags.
This patch will build NamedMetadata for DXIL validation version and remove the code to rebuild ModuleFlags.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130207
Only remove dx.valver from module flags when cleanup module flags in DXILTranslateMetadataPass.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D125842
A new pass DxilEmitMetadata is added to translate information saved in llvm ir into metadata to match DXIL spec.
Only generate DXIL validator version in this PR.
In llvm ir, validator version is saved in ModuleFlag with "dx.valver" as Key.
!llvm.module.flags = !{!0, !1}
!1 = !{i32 6, !"dx.valver", !2}
!2 = !{i32 1, i32 1}
DXIL validator version has major and minor versions that are specified as named metadata:
!dx.valver = !{!2}
!2 = !{i32 1, i32 7}
Reviewed By: kuhar, beanz
Differential Revision: https://reviews.llvm.org/D125158
