Standard Portable Intermediate Representation

Standard Portable Intermediate Representation (SPIR) is an intermediate language for parallel compute and graphics by Khronos Group. It is used in multiple execution environments, including the Vulkan graphics API and the OpenCL compute API, to represent a shader or kernel. It is also used as an interchange language for cross compilation.
SPIR-V was introduced in 2015 by the Khronos Group, and has since replaced the original SPIR, which was introduced in 2012.
Purpose.
The purposes of SPIR-V are to natively represent the primitives needed by compute and graphics; to separate high-level language from the interface to compute and graphics drivers; to be the distribution form, or distribute fully compiled binaries; to be a fully self-contained specification; and to support multiple APIs. It is also used as an intermediate target for cross-compilation tools. 
For example, SPIR-V allows the Vulkan API to use any shading language, including GLSL and HLSL. SPIR-V can be compiled into several shading languages (GLSL, GLSL ES, MSL, HLSL) using SPIRV-Cross, so that these languages can be interconverted. It also has paths to and/or from WebGPU, OpenCL, SYCL, C++, and Rust.
In target platforms, ingesting SPIR-V removes the need to build a high-level language source compiler into device drivers, which reduces driver complexity.
Versions.
SPIR was originally introduced in 2011 and SPIR-V was introduced in 2015.
LLVM-based versions.
SPIR prior to the 2015 SPIR-V release was based on the LLVM Intermediate Representation. A provisional specification for SPIR 1.0 was announced in 2012. On July 22, 2013, a provisional specification SPIR 1.2 was announced at SIGGRAPH 2013. The final SPIR 1.2 specification was released at HiPEAC 2014 on January 21, 2014. On August 11th, 2014, a provisional specification for SPIR 2.0 was released at SIGGRAPH 2014. SPIR-V does not use LLVM.
SPIR-V.
SPIR-V 1.0 is a new version of SPIR announced in March 2015, and released on November 16, 2015. The SPIR family now includes a true cross-API standard that is fully defined by Khronos with native support for shader and kernel features.
A separate program by the Khronos Group allows for interconversion with LLVM IR.
Support for ingestion of SPIR-V is incorporated in the core specification of OpenCL 2.1, the Vulkan API, and OpenGL version 4.6.
Features.
SPIR-V is a high-level intermediate language, exchanged in binary form. Functions are represented by a control-flow graph of basic blocks, using static single assignment (SSA) form. Data structures retain high-level hierarchical representation. It is not lossy like previous byte-code or virtual machine-like intermediate representations used for graphical shaders. This allows closer to optimum performance on the target devices. 
Extensibility.
SPIR-V can be extended by writing extensions to add semantics, or reserving ranges of the token values for the party's use. Vendors can independently add desired semantics to SPIR-V. Additional sets of extended instruction sets can be provided in separate specifications. Multiple sets can be imported without issue, as extended instructions are used by specifying the ID of the set and of the instruction within the set.
Shaders.
Debuggers include RenderDoc, SwiftShader, and Amber.
Graphical shaders use structured control flow in SPIR-V to state how control flow nests. This helps in defining divergence and reconvergence of control flow on parallel execution environments. Specialization reduces the number of variants of a shader that need to be distributed.
Validation.
The SPIR-V specification states the rules that must be followed to have a valid SPIR-V module. This allows for offline validation. Drivers are not obligated to handle invalid SPIR-V modules. In testing, conformance testing verifies that drivers behave correctly when consuming valid SPIR-V, while validators verify that front-ends properly generate SPIR-V. 
Linking.
SPIR-V can express calls to functions in a different compilation unit. The standard version of SPIR-V uses this feature for OpenCL compute kernels, but not for shader stages, which the graphical APIs want fully linked into a single SPIR-V module. There are extensions available to allow tools to temporarily use partially linked shaders and also kernels.
Capabilities.
A SPIR-V module is used by a client API to support that module's features, which are classified through capabilities, and declared early in the module. A validator can confirm that the module uses only its declared capabilities, and a client API can reject modules that declare unsupported capabilities.
SPIR-V for GLSL Cross-Compilation.
SPIR-V has been used to help deal with multiple versions of source-level languages. For example, the multiple versions of OpenGL Shading Language (GLSL) require distribution of multiple versions of shaders, due to implementations that are pegged to a specific older version of GLSL, such as for WebGL 1.0 and Apple's OpenGL implementation. One of the notable use cases of SPIR-V is its ability to be used as an interchange format between GLSL versions, using tools maintained by the Khronos Group for compiling GLSL to SPIR-V codice_1, optimizing SPIR-V codice_2, and cross-compiling to SPIR-V to different GLSL targets codice_3.
As a format, however, SPIR-V has some limitations for cross-compilation, including the requirement that every SPIR-V module have at least one entry-point symbol. This prevents the format from being easily used for separate compilation, where complex shaders could be assembled by a series of partial compile steps followed by a linking step. This runs counter to the stated goals of some SPIR-V tools such as codice_4, which aims to provide full linking functionality for SPIR-V binary code.