It's worth noting that SPIR-V isn't really compiled for the target ISA, it's not even guaranteed to be in a particular optimized form already.. so when the GPU driver loads it, it may or may not decide to spend a lot of time running optimization passes before translating it to the actual machine code the GPU needs.
In contrast, Metal shaders can be pre-compiled to the actual ARM binary code the GPU runs.
And DirectX shader bytecode, DXIL, is (poorly) defined to be a low-level IR that LLVM spits out right before it would be translated to machine code, rather than a high-level IR like SPIR-V is. i.e. it is guaranteed to be in an optimized form already, so drivers do not expect to run any optimizations at load time.
SPIR-V seems a bit of a mess here, because you don't really know what the target GPU is going to do - and what you can expect in terms of time the GPU spends on optimizing the SPIR-V when loading it varies on mobile and non-mobile GPUs, depending basically on what the GPU manufacturer felt behaved the best based on how random people making games distribute optimized or unoptimized SPIR-V.
Valve even maintains a fancy database of (SPIRV, GPU driver) pairings which map to _actual_ precompiled shaders for all games distributed on their platform, so that they aren't affected by this.
Which is really how the experience with portable APIs from Khronos goes, most people that claim they are portable never really did any serious cross platform, cross device programming with them.
At the end of the day there are so many if this, if that, load this extension, load that extension, do this workaroud, do that workaround, that it could just be another API for all pratical purposes.
