We don't use glsl shaders at all (aside from meta crap). We generate SPIR-V directly from DXBC then apply our own transformations if per-say, we need to handle mismatched input layouts or in d3d9, enable flat shading.
DXVK already does more or less what you propose. The DXBC->SPIR-V translation happens inside Create{Vertex,Pixel,...}Shader (see https://github.com/doitsujin/dxvk/blob/2cac70fbb6bc3e9d69c29082b66dfa7b639432cc/src/d3d11/d3d11_shader.cpp#L39-L41), at draw time we only fix up binding numbers in SPIR-V etc and create the VkPipeline, which can take hundreds of milliseconds per pipeline depending on the driver.
Note that D3D has no concept of a program object like OpenGL does. Instead, individual shaders are bound to the context, so it is impossible for us to even know which shaders are used together until they are being used in a draw. In other words, we simply cannot do anything at link time because there is no link time.
Excellent, just wanted to make sure this opportunity is not missed.
Nothing extracted yet.
I recently learned that dxvk compiles shaders at draw time (this confirms it). We use to do the same in ANGLE, and I can understand why dxvk would choose to do that.
A while back however, I solved this issue in ANGLE by compiling the shaders at (GL) link time and applying a simple SPIR-V transformation on draw if necessary. dxvk could do the same, which should help reduce the stuttering in some games (VkPipelines are still created at draw time, especially because some internal push constants can only be determined at run time, but it's always possible to compile "the most common" setting at link time and hope for a hit). I intend to move the compilation to (GL) compile time even (which is currently not done because the transform feedback code is generated in GLSL at link time, but that could also be done on SPIR-V directly).
You can take a look here (see SpirvTransformer) for inspiration.