[RFC] Proposal to establish a Safety Group in LLVM

Community
1

Abstract

This RFC proposes the creation of a Safety Group within the LLVM project, similar to the existing Security Group. The group would serve as a community-driven forum to address the challenges of using LLVM in safety-critical systems development, such as those governed by ISO 26262 (automotive), DO-178C (aerospace), or EN 50128 (railways). It would focus on enabling qualified use of LLVM components through shared infrastructure, quality best practices, documentation, collaboration, and long-term planning.

Motivation

LLVM is increasingly adopted in safety-critical domains, but it currently lacks an organized space to address the specific needs of functional safety, such as:

  • Compiler qualification under ISO 26262 or equivalent standards
  • Toolchain confidence arguments and documentation
  • Traceability, change management, and release discipline
  • Integration of safety-relevant artifacts and practices
  • Coordinated engagement with users in regulated industries

Technical talk at AsiaLLVM 2025

At AsiaLLVM 2025, I presented a technical talk titled “LLVM in the Automotive Industry: Bringing Functional Safety to Open Source”, explaining the importance and interest in addressing an open, upstream qualification of LLVM. One of the proposals is to create a dedicated “Safety Group” that would allow collaboration and open up opportunities for new contributors, institutions, and organizations with safety-critical use cases.

Summary of the talk: (Note: the recording and the slides will be published here)

  • Safety-critical industries such as automotive, medical, and aerospace increasingly rely on complex software, with systems like ADAS and autonomous driving demanding extreme levels of assurance. Safety standards like ISO 26262 require that tools used in the development of such systems, including compilers, be justified through “confidence in use”, a structured argument that they do not introduce or fail to detect defects.
  • Compiler infrastructures like LLVM are at the heart of the development of these systems, but the components of LLVM are not qualified upstream. While some vendors have performed private qualification of their LLVM-based compilers, these efforts are fragmented, costly, and duplicative. At the same time, LLVM does not currently have structured quality evidence aligned with safety standards, making qualification difficult to scale or reuse.
  • At AsiaLLVM 2025, I presented these challenges and argued that a shared, open approach to qualification could reduce duplication and enhance trust. This RFC proposes creating a Safety Group within LLVM to serve as a forum for systematically addressing these concerns.

Proposal

We propose forming an LLVM Safety Group as an interest-driven working group. Its scope would include:

  • Providing a central forum for discussing safety-related topics in LLVM.
  • Developing guidance and documentation on using LLVM in safely-related developments.
  • Collaborating on common infrastructure (e.g., qualification kits, coverage tools, test suites, formal methods).
  • Identifying areas of the codebase where safety-relevant improvements may be needed
  • Coordinating with upstream maintainers on proposed safety-driven contributions.
  • Facilitating interaction with companies, tool vendors, quality and safety auditors, where appropriate.

The group would not enforce policy or process, or maintain exclusive control over any part of LLVM. Instead, it would serve as a bridge between safety users and the existing LLVM project structure.

Other open source projects (e.g., Zephyr RTOS, Eclipse Foundation, Linux Foundation,…) have created dedicated working groups to coordinate safety-related activities and collaborate on standards alignment.

Initial steps for the Safety Group

If this RFC is accepted, the Safety Group could begin with the following concrete actions:

  • Create a dedicated Discourse category or tag for safety-related discussions.
  • Hold a public kickoff call to gather interested contributors and align on short-term priorities.
  • Propose an initial scope for qualification (e.g., What components of the infrastructure? What parts of LLVM core? Specific frontend(s)? What target(s)?).
  • Propose specifications and mechanisms for traceability with tests.
  • Propose solutions for analysis of bug reports, such as marking safety-relevant bugs or commits and defining countermeasures or workarounds.
  • Identify 1–2 low-risk upstream patches that could improve safety posture (e.g., test coverage, documentation).
  • Compile existing safety-relevant work from vendors, research, and prior art to identify common gaps and reusable patterns.
  • Draft an initial “Safety Users Guide to LLVM” or “LLVM Safety Manual”, a lightweight document mapping LLVM use cases to common safety concerns and outlining some known usage assumptions or constraints.

These steps are intended to be non-disruptive and collaborative. They are focused on gathering shared knowledge, creating infrastructure that benefits all users (safety-critical or not), and building trust.

Deliverables

Focus areas might include:

  • Reference process for qualification, including validation and audit.
  • Common confidence argument templates or evidence patterns.
  • Proposals for traceability mechanisms (e.g., bidirectional mapping between specs and tests) across versions.
  • Analysis of known issues and proposal of workarounds or countermeasures, where appropriate.
  • Safety manual for LLVM components.

Participation and Format

We envision the group as open to all interested community members, including:

  • Contributors from safety-critical industries.
  • Tool vendors and integrators.
  • Compiler engineers with experience in verification.
  • Academics and researchers in compilers and reliability.

Discussions would take place primarily via:

  • A new category on LLVM Discourse.
  • Periodic virtual meetings or ad hoc working sessions.
  • Collaborative documents and open RFCs.

Open Questions

  • What is your opinion on the interest of this Safety Group? Do you, as part of the LLVM community, see its creation as useful and understandable, and as a collaborative opportunity?
  • If Yes:
    • Should the group interface with other existing LLVM working groups (e.g., release engineering, security)?
    • Should the group propose changes to release practices to aid qualification?
    • Should the group support other areas or topics than those mentioned in this RFC to give more value to the LLVM community?
24 Likes
LLVM Qualification WG sync-ups meeting minutes
LLVM Weekly - #599, June 23rd 2025
2

@davidchisnall @nlopes @TobiasGrosser @jrtc27

1 Like
3

I’d like to voice my support for this. Sounds like a valuable undertaking.

I would like to also contribute, if you need extra hands. I’m one of the two code owners for RealtimeSanitizer. Happy to help if you find it’d be useful.

1 Like
4

Thank you for your support @cjappl I appreciate your offer to contribute!
Having someone with your experience (especially as a code owner for RealtimeSanitizer) would be incredibly valuable. Runtime diagnostics, testing infrastructure, and reproducibility are important areas for safety use cases, and I’d love to explore where your expertise could fit in. I’d be happy to connect in the meantime if you have ideas or suggestions you’d like to share. Thanks again!

5

I would like to voice my support for this.

It’s essential to have OSS tooling that can be used in the safety critical context.

I am also available to help out in any way that it makes sense. I have been developing safety critical systems in different verticals for the past 18 years.

1 Like
6

Thank you for your support @jr-simoes and for offering to help. With your background across safety-critical domains, your input could be incredibly valuable, especially as we shape the early scope and priorities for the group. If you have suggestions based on your experience, whether it’s around tooling expectations, qualification challenges, or collaboration models that worked well, I’d love to hear them. Really appreciate you joining the conversation!

1 Like
7

It’s not a small endeavour :grinning_face:

It would be great to be able to split the work into 3 separate components. Frontend for language specific things, backend for the target specific things and middle-end for optimisations. This would have the advantage of being possible to bring new features in one of these components without having to qualify everything.

I can foresee a lot of issues. Any language feature that can cause UB, targets with incomplete specification and erratas.

For the middle part, and this is probably my lack of knowledge speaking, I’m not sure what can be achieved. We need specification to start and I don’t know if this exist.

Maybe ferrocene could help as they have done similar work for rust.

3 Likes
8

Full disclosure: I work at the same company as @uwendi.

Anyway, I think that bringing qualification into the open for LLVM could have a very big impact on the safety critical toolchain landscape, and potentially deduplicate a lot of work.

I think that a lot of the stuff that needs to be done for safety qualification is generally partially present in LLVM (e.g. we have documentation that partially satisfies the requirements of a safety manual, ISO26262-compliant user manual, etc.) I don’t think that tidying these things up imposes any burden on the community.

Collaboration with an external company like Ferrocene would be good.

It would be very cool to see an OSS-qualified toolchain (or toolchain certified using the OSS qualification process) be used in industry, and I think it would make a huge difference in how many safety critical industries do software development today.

2 Likes
9

@jr-simoes Thank you, I really appreciate this thoughtful breakdown.

It’s clear this isn’t a small endeavor, and decomposing it into frontend, middle-end, and backend components is a sensible approach.

Regarding the middle-end, you’re not alone in questioning this part. That’s were most of LLVM’s power and magic lives. We need to explore how much of a formal, stable interface or specification exists; reasoning about transformations there could be tough, but very interesting. Some form of abstraction or even partial scoping could help. For example:

  • Cataloguing the middle-end passes (like “always safe and semantics-preserving”, “potentially unsafe or non-deterministic”, “configurable or optional”) to explicitly whitelist/blacklist passes before analysis.
  • Defining IR-level invariants, to clearly state what must hold at the LLVM IR level between stages. That could create a partial functional specification of the middle-end’s role, and restrict the I/O expectations.

For the latter, it would be really helpful to have contributors from academia or people who have studied formal verification of optimizers, translation validation, and equivalence checking (e.g., Alive2, which was among the examples I presented at the conference).

We don’t need to try to do it all at once. Starting with a small and easily auditable pass sequence would be nice. Let’s explore your modular breakdown more, co-developed with the group :wink:

10

Hi @barrelshifter :smiling_face:

Yes, many of the building blocks needed for qualification are already at least partially present in LLVM, whether it’s in documentation, test infrastructure, or even community practices. What’s missing, in many cases, is a more structured and safety-aligned presentation of those artifacts. Having complete and correct specifications for some parts could be a difficult but interesting challenge though. I believe we can improve that without disrupting the community, especially because our goal is to clarify and organize, not impose.

The point about deduplication is especially important. If we can define common ground for confidence arguments, building good foundations, we not only reduce effort but we also improve consistency and transparency across the ecosystem.

An upstream safety group or qualification framework could enhance any downstream toolchain.

Ferrocene or similar organizations could absolutely bring valuable expertise, and I’d be happy to explore how we could collaborate on upstream-facing pieces if they want to join.

Thanks for contributing to the conversation! :grinning_face_with_smiling_eyes:

1 Like
11

@uwendi Thank you for initiating this. Are we looking to create a core group Safety similar to security group member? Is the participation open to anyone?

LLVM Security Response Group — LLVM 21.0.0git documentation

1 Like
12

I’d be happy to be involved with this effort in some fashion. I’m involved with Alive2, which of course is primarily Nuno’s project. But also I’m the main person working on Alive2-based translation validation for LLVM’s aarch64 and riscv64 backends.

1 Like
13

@uwendi Thanks for starting this and great talk at AsiaLLVM 2025. We at Quadric are very supportive of this effort and would be happy to be involved.

1 Like
14

@mrragava Thanks, I appreciate your interest.

The vision is somewhat similar in spirit to the LLVM Security Group in that it would provide a space for coordination around a specific domain (in this case, safety, and more generally quality). However, unlike the Security Group which has a more closed membership for handling sensitive reports, the LLVM Safety Working Group would be completely open to participation.

The idea is to create an inclusive space where contributors, safety practitioners, toolchain users, and anyone interested in qualification or assurance can collaborate, whether through discussions, documentation, reviews, or just sharing ideas.

You’re very welcome to join!

15

@regehr Thank you, that’s fantastic to hear!

Your work on Alive2 and translation validation is highly relevant, especially as we start thinking about what “confidence in transformations” might look like in a safety context. Having validation coverage for backends like AArch64 and RISC-V could be a strong piece of a qualification argument, or at least a foundation to build on :grinning_face_with_smiling_eyes:

I’d love to explore how this kind of infrastructure could fit into the group’s scope, or even shape early deliverables (e.g., a map of existing qualification-supportive tools in LLVM).

I should share a follow-up post soon with next steps and a signup form :thinking:
It would be great to include you in those discussions!

1 Like
16

Thank you so much @ndrego It was a pleasure meeting you at AsiaLLVM! I really appreciate the kind words and support, and am happy that this talk resonated.

It’s great to hear again that Quadric is supportive :blush: Having backing from organizations like yours helps show and confirm that this initiative reflects a real and shared need in the community. Would be very glad to have you or others from your team join when the time is right.

I’ll be posting a follow-up shortly with details on how to stay involved.

Thanks again for reaching out. Let’s keep in touch!

17

Hi Wendi, this is Shivam. I strongly support creating a Safety Group as the the automotive industry’s increasing reliance on LLVM for ADAS/autonomous systems makes this both timely and necessary, and I can tell you about the company like Ferrous System(Who created Ferrocene) and KDAB(Working on different C++ Projects including working for Automotive industry), We are quite interested in making this possible and we had different meetings on the topic.

I was researching on the topic from quite a while, and my key suggestions: (1) Start with a focused scope targeting ISO 26262 ASIL-B/C qualification for Clang frontend + core optimization passes rather than attempting full LLVM qualification initially, (2) Establish partnerships with existing commercial qualification vendors (like Ferrocene approach for Rust) to leverage proven methodologies while maintaining open-source principles, (3) Create a tiered membership model where safety-critical companies can contribute resources for qualification infrastructure while keeping all resulting artifacts open-source, (4) Interface closely with the existing Security Group since many security practices (reproducible builds, supply chain integrity, formal verification) directly support safety arguments, and (5) Develop a “Safety-First” testing methodology that extends LIT with systematic requirements traceability and evidence generation capabilities.

And finally the group should also coordinate with automotive OEMs early to ensure the qualification approach will be accepted by functional safety auditors, as upstream community buy-in means little if the end result isn’t certifiable in practice.

Thanks for your talk at AsiaLLVM and now for your RFC.

1 Like
18

Naming recommendation: “safety” is a heavily overloaded term. As someone not in the affected industries, the term “certification” has been the most useful for me to distinguish the discussions. (Even though the precise mechanic is to make the compiler a “qualified tool”, certification of the final binary is still the recognizable goal.)

So, I suggest this be named as the “Certification Group”.

1 Like
19

Speaking of security and ISO26262, there is an ongoing effort (first time presented on LLVMDev in 2020, last time presented on this year’s Euro LLVMdev) to use Clang for security/Autosar/MISRA checks and have an open-source alternative to current proprietary checkers.

More info at:
https://llvm.org/devmtg/2025-04/slides/lightning_talk/todorovic_autocheck.pdf

3 Likes
Changes for MISRA/AUTOSAR coding standards
20

This is very interesting.

I work on the (unreleased) SYCL SC specification (SYCL for Safety-Critical Systems). All active SYCL (not SYCL SC) implementations are based on LLVM, so the intersection of LLVM and functional safety is directly relevant to us.

I don’t immediately know what I’d be able to contribute to an LLVM safety group, but I’d definitely like to be in the loop.

1 Like