================
@@ -4779,6 +4739,18 @@ void Driver::BuildActions(Compilation &C, DerivedArgList
&Args,
}
}
+ if (C.getDefaultToolChain().getTriple().isSPIRV()) {
+ const auto &TC =
+ static_cast<const toolchains::HLSLToolChain
&>(C.getDefaultToolChain());
+
+ // Call spirv-val for SPIR-V when -Vd not in Args.
+ if (TC.requiresValidation(Args)) {
+ Action *LastAction = Actions.back();
+ Actions.push_back(
+ C.MakeAction<BinaryAnalyzeJobAction>(LastAction, types::TY_Object));
----------------
bogner wrote:
DX_CONTAINER is a different thing - the compiler can emit DXIL object files
(which are just bitcode) or an entire DXIL container (which has various parts,
one of which is the bitcode). That example isn't relevant here.
Given that spirv-val doesn't modify the object at all I think it should either
have the type of the input (which is indeed `types::TY_OBJECT` or it shouldn't
have an output at all (`types::TY_Nothing`).
We also do need to check that `LastAction->getType() == types::TY_Object` here
so we don't try to run the validator if the previous action isn't producing a
SPIR-V object. This can happen if we specify some other flags such that the
compiler is stopping early or something
https://github.com/llvm/llvm-project/pull/188150
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
