[llvm] [DXIL] Consume Metadata Analysis information in passes (PR #108034)
S. Bharadwaj Yadavalli via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 19 10:25:05 PDT 2024
================
@@ -58,25 +89,257 @@ static void emitResourceMetadata(Module &M, const DXILResourceMap &DRM,
}
if (!HasResources)
- return;
+ return nullptr;
NamedMDNode *ResourceMD = M.getOrInsertNamedMetadata("dx.resources");
ResourceMD->addOperand(
MDNode::get(M.getContext(), {SRVMD, UAVMD, CBufMD, SmpMD}));
+
+ return ResourceMD;
+}
+
+static StringRef getShortShaderStage(Triple::EnvironmentType Env) {
+ switch (Env) {
+ case Triple::Pixel:
+ return "ps";
+ case Triple::Vertex:
+ return "vs";
+ case Triple::Geometry:
+ return "gs";
+ case Triple::Hull:
+ return "hs";
+ case Triple::Domain:
+ return "ds";
+ case Triple::Compute:
+ return "cs";
+ case Triple::Library:
+ return "lib";
+ case Triple::Mesh:
+ return "ms";
+ case Triple::Amplification:
+ return "as";
+ default:
+ break;
+ }
+ llvm_unreachable("Unsupported environment for DXIL generation.");
+}
+
+static uint32_t getShaderStage(Triple::EnvironmentType Env) {
+ return (uint32_t)Env - (uint32_t)llvm::Triple::Pixel;
+}
+
+namespace {
+enum EntryPropsTag {
+ ShaderFlagsTag = 0,
+ GSStateTag,
+ DSStateTag,
+ HSStateTag,
+ NumThreadsTag,
+ AutoBindingSpaceTag,
+ RayPayloadSizeTag,
+ RayAttribSizeTag,
+ ShaderKindTag,
+ MSStateTag,
+ ASStateTag,
+ WaveSizeTag,
+ EntryRootSigTag,
+};
+} // namespace
+
+static SmallVector<Metadata *>
+getTagValueAsMetadata(EntryPropsTag Tag, uint64_t Value, LLVMContext &Ctx) {
+ SmallVector<Metadata *> MDVals;
+ MDVals.emplace_back(
+ ConstantAsMetadata::get(ConstantInt::get(Type::getInt32Ty(Ctx), Tag)));
+ switch (Tag) {
+ case ShaderFlagsTag:
+ MDVals.emplace_back(ConstantAsMetadata::get(
+ ConstantInt::get(Type::getInt64Ty(Ctx), Value)));
+ break;
+ case ShaderKindTag:
+ MDVals.emplace_back(ConstantAsMetadata::get(
+ ConstantInt::get(Type::getInt32Ty(Ctx), Value)));
+ break;
+ default:
+ llvm_unreachable("NYI: Unhandled entry property tag");
----------------
bharadwajy wrote:
> It'd be better to spell out all of the cases so that we get a covered switch diagnostic if one is missing. I'd even argue it might be better to leave the unimplemented ones out of the enum until we support them so it's easier to see where all we need to make updates, though that is a little bit awkward since we'd need gaps in the enum for now.
I did leave the unimplemented enums in with an intent to keep them on record to add future support. I am not opposed to deleting them if there is a strong objection or some LLVM convention for such situations.
https://github.com/llvm/llvm-project/pull/108034
More information about the llvm-commits
mailing list