[llvm] [DirectX backend] emits metadata for DXIL version. (PR #88350)

[Chris B via llvm-commits]

================
@@ -81,6 +81,18 @@ void dxil::createShaderModelMD(Module &M) {
   Entry->addOperand(MDNode::get(Ctx, Vals));
 }
 
+void dxil::createDXILVersionMD(Module &M) {
+  Triple TT(M.getTargetTriple());
+  VersionTuple Ver = TT.getOSVersion();
----------------
llvm-beanz wrote:

Apologies for any confusion caused by me posting the comment from an alternate account (@thegreatbeanz) is me.

I can't share anything about future plans for HLSL or DXIL, aside from what is already public. That said, I don't think we need to consider future plans to see the potential benefit of keeping DXIL and SM versions separate and clearly defined.

We haven't done a great job delineating shader model versions from DXIL versions in DXC, but they are different. A good example is the quadVote DXIL Op (described [here](https://microsoft.github.io/DirectX-Specs/d3d/HLSL_SM_6_7_QuadAny_QuadAll.html)). While the quadVote DXIL Op was added in DXIL 1.7, the QuadAny/QuadAll HLSL intrinsics were retroactively added back to Shader Model 6.0 because they can be lowered to different DXIL operations on older DXIL versions. We've also done this for other new functions like the `IsHelperLane` intrinsic added in [Shader Model 6.6](https://microsoft.github.io/DirectX-Specs/d3d/HLSL_ShaderModel6_6.html).

This means there isn't a 1:1 mapping between source-level intrinsics where shader model is our versioning, and DXIL operations where the DXIL version is our mechanism.

When we think about expanding DXIL targeting support to other languages, it is probably more clear to separate the Shader Model version (which is an HLSL concept) from the DXIL version (which is a code-generation concept). 

https://github.com/llvm/llvm-project/pull/88350