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

[Tex Riddell 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();
----------------
tex3d wrote:

> 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).

This sounds wrong.  Shader Model is specifically a target constraint concept applying to the features used in the IR we pass to drivers.  DXIL version is an IR versioning concept.  In the past, if something in HLSL could be mapped to the constraints in a shader model by the compiler, then it was legal to use in that shader model.  It was never considered an HLSL concept/constraint.  We may want to put constraints on HLSL APIs in the future based on the shader model used, but that is not the core role *of* the shader model.

We also add things to the language/API in shader model time frames, but that doesn't mean that using those things at the source level always requires compilation to those shader models.  They just require a new enough compiler that has the source-level construct (like `QuaAny`/`QuadAll`/`IsHelperLane`).

In the past, they have advanced in lock-step because with each new shader model, we have needed updates to DXIL, making it necessary to advance that version, and we can't use a newer DXIL version for an older shader model, since drivers reporting support for a particular shader model are not expected to support any newer DXIL versions beyond that shader model.

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