[RFC] Promoting SPIR-V to an official target

LLVM Project
, , ,
1

LLVM Community,

We are writing to propose promotion of the SPIR-V backend from its current experimental to an official status within the LLVM project. Over the past three years, the SPIR-V backend has seen significant advancements in functionality, stability, and community support and has become an important piece of software for multiple downstream projects.

Overview of SPIR-V and SPIR-V backend

SPIR-V is an intermediate representation defined by the Khronos Group. It serves as a cross-vendor unifying IR for programming heterogeneous accelerators such as GPUs, FPGAs, NPUs, and also CPUs. SPIR-V is integral to a rich ecosystem of high-level languages and APIs, including OpenCL, Vulkan, SYCL, GLSL, and HLSL, and works as a portable binary format for their compilers and drivers.

Current Status and Prospects

The SPIR-V backend has been deeply transformed and matured since its initial introduction as an experimental target in March 2021. We have incorporated feedback from the initial RFC and Phabricator comments, refined alignment with the general GlobalISel workflow, and introduced numerous customer-requested features, including SPIR-V extensions, builtins, and LLVM intrinsics. By improving the backend architecture and aligning it with GlobalISel requirements, we have enhanced the correctness of Machine IR between passes.

We have presented our solutions to these challenges at the LLVM Developers’ Meetings in 2022 and 2024. Contributors from multiple organizations, including AMD, Google, Intel, and Microsoft actively participate in the development and maintenance of the project.

The SPIR-V backend is built to serve both compute kernel and graphics shader developers equally. We collaborate closely with the Khronos OpenCL, SPIR, and Vulkan working groups to ensure that the backend aligns with the needs of the broader development community. Recently, Khronos Group acknowledged these efforts in its RFP, stating the following: “…due to ongoing developments and contributions from various SPIR-V vendors, the backend is anticipated to fully supplant the translator”.

When it comes to compute kernel support, the backend has achieved OpenCL 3.0 conformance. Over the past year, we also reached a ~99% SYCL CTS pass rate across all optimization levels and are nearing full SYCL conformance. With 31 SPIR-V extensions already implemented and more planned in the near future, the backend stands as a robust alternative to the Khronos SPIR-V LLVM Translator. Intel intends to leverage the SPIR-V backend in SYCL/DPC++ compiler and its XPU backend for Triton compilation flows.

There is ongoing work to support Vulkan and HLSL in the SPIR-V backend. Recently the community has also learned that Microsoft is going to adopt SPIR-V in DirectX 12. Their HLSL team already plays a vital role in the SPIR-V backend development.

The project also now facilitates integration and offers better compatibility with external tools and libraries previously relying on Khronos SPIR-V LLVM Translator to produce SPIR-V from LLVM IR.

Requirements for Official Targets

The SPIR-V backend satisfies the criteria specified for official targets in the LLVM Developer Policy:

  • Maintainers: The backend is actively maintained by a team of dedicated contributors from multiple organizations.
  • Active Community: Current development is discussed bi-weekly by LLVM SPIR-V Backend Working Group (open to the public).
  • Code Compliance: The backend’s code conforms to LLVM’s coding standards and policies. There are no contentious issues affecting standard CodeGen flow.
  • Documentation: SPIR-V spec and comprehensive documentation are available.
  • Stability Period: The backend has been stable in-tree for more than two years now.
  • Testing and Buildbots: Extensive test coverage with many small tests has been established. The backend passes the check-all build target, and a public GitHub Action validating SPIR-V was added to ensure correctness of new patches.

We have defined internal QA requirements and established processes to ensure rigorous testing and validation of the generated code, focusing on the backend’s stability and correctness. This effort included significantly enhancing test coverage with over 500 new LIT tests, integrating machine verifier and Khronos SPIR-V validation tooling as a standard practice for new test cases, run through GitHub Actions on each pull request. We also run regular working group meetings.

Future Work and Ongoing Efforts

Looking ahead, there are ideas to develop a SPIR-V consumer within LLVM, potentially sharing code with the backend. This initiative could benefit projects like SYCL/DPC++, providing a more integrated and efficient workflow. We are also working on porting additional tests from the Khronos SPIR-V LLVM Translator.

We encourage community contributions to support more SPIR-V extensions, address any remaining corner cases, or report any issues!

Request for Comments

Promoting the SPIR-V backend to an official target will significantly benefit the LLVM project and its users. We welcome any feedback from the community regarding this proposal.

CC: @VyacheslavLevytskyy, @Keenuts, @chouinard, @rengolin, @MaskRay, @jdoerfert, @nikic, @kuhar, @arsenm, @beanz, @bogner, @s-perron, @MrSidims, @AlexVlx, @efriedma-quic

11 Likes
2

GitHub pull request adding SPIRV to LLVM_ALL_TARGETS: [SPIR-V] Add SPIRV to LLVM_ALL_TARGETS by michalpaszkowski · Pull Request #119653 · llvm/llvm-project · GitHub

3

I support this move.

I remember when SPIR-V was added as a target back then, and honestly thought it had been moved to an official target a long time ago. I was surprised recently to discover this isn’t the case, since it has been following the criteria for official targets for years.

4

I generally support the move. I think the SPIRV target meets our standards for official targets.

There are two SPIRV-specific concerns I want to discuss:

  • SPIRV has a (default-disabled) LLVM_INCLUDE_SPIRV_TOOLS_TESTS option, which builds additional tools for testing from a 3rd-party repository. These are then conditionally used in most tests. Is there any significant risk that developers who don’t enable this option (i.e. anyone not working on SPIRV) will break tests using it?

  • SPIRV is significantly different from other (non-DirectX) targets in that it produces a fairly high level IR whose design is inspired by how LLVM looked like a decade ago. In particular, without the SPV_KHR_untyped_pointers extension, SPIRV uses typed pointers, which caused major complications during the opaque pointers migration. I’d like to understand to what degree we can expect SPIRV to cause problems for future changes to LLVM IR design. For example, would any of the following changes require substantial work for SPIRV support?

    • Migrating getelementptr to ptradd ([RFC] Replacing getelementptr with ptradd). In short, only supporting getelementptr i8, ptr %p, i64 %offset, with the offset calculation being explicit.
    • Only specifying type size in allocas (and byval etc). In short, replacing alloca %T with alloca [sizeof_T x i8].
    • Representing global initializers as bags of bytes with relocations. In short, composing all initializers from sequences of [N x i8] and ptr only.

    If they require substantial work, can SPIRV maintainers commit to making any necessary changes in a reasonable time-frame (days, not years)?

1 Like
5

In my experience, SPIR-V backend has been frequently broken. It was also the last backend that adopted opaque pointers (or did it not?).

Nonetheless, I’m in favor of moving this backend to regular ones. I’d also vote for moving all other backends out of experimental state with the exception of DirectX (unstable) and Xtensa (in early development).

6

I don’t know the details, but it is generally harder to maintain an experimental target than an official one, and this is one of the key reasons we don’t leave them hanging for too long.

Each backend needs to be considered on their own rights. Let’s not cross wires here. This is solely about the SPIR-V backend.

7

Thank you @rengolin! Thank you @nikic!

These tests primarily verify SPIR-V specification compliance by using the spirv-val tool from Khronos SPIR-V Tools. For developers not directly involved with SPIR-V, standard CHECK lines in our LIT tests should be (and are so far) sufficient to catch regressions. Major changes to the SPIR-V backend itself, such as introducing new features or extensions, inherently require knowledge of the SPIR-V specification, and spirv-val can be a valuable resource for newcomers in that scenario.

Moreover, every issue previously detected by spirv-val is now also covered by explicit LIT tests with standard CHECK lines – and this will remain our objective. Thus, enabling LLVM_INCLUDE_SPIRV_TOOLS_TESTS remains optional and serves as an extra safety net rather than burden on non-SPIR-V developers.

At a high level, SPIR-V specification really follows LLVM’s developments. Ensuring the ability to translate between the two IRs is critically important for SPIR-V consumers, many of whom rely heavily on LLVM for the compiler-driver. We remain aware of planned LLVM IR changes, both as SPIR-V backend developers and as contributors to the specification.

Most of the proposed LLVM IR changes you mentioned align with the ongoing efforts around the SPV_KHR_untyped_pointer extension. I do not foresee any major rework in the SPIR-V backend since the untyped pointer infrastructure (type deducing pass, intrinsics marking pointer and builtin types etc.) is already in place. Those are constantly improved and will need to be expanded/changed as we won’t be able to rely on allocas and will need to do similar scavenging for global initializers. The opaque pointers migration was a different scenario, as it required adjustments not only in the SPIR-V backend but also in LLVM IR itself due to a.o. SPIR-V (e.g. TargetExtType), and in downstream compilers using the backend.

We believe our commit track record over the past months and year speaks to our readiness. Contributors from multiple organizations commit changes every week, development is highly active, and we have maintained a stable state. I think this level of maintenance and collaboration positions us well to handle any required adaptations quickly.

3 Likes
8

Thanks for the response @michalpaszkowski, it addressed all my concerns.

1 Like
9

+1 for promoting SPIRV; I agree it is sufficiently mature and well-supported, despite being (necessarily) unusual.

-1 for expanding the discussion to “all other backends”; each such backend should write its own proposal like this.

10

For the record, I didn’t suggest discussing it here. It was my justification for promoting SPIRV target to official ones (probably poorly worded).
I already regret positng that.