New clang::driver::ToolChain acceptance criteria

Clang Frontend
1

For a given target triple (build-time LLVM_DEFAULT_TARGET_TRIPLE, overridden by --target=), Clang selects a clang::driver::ToolChain under
https://github.com/llvm/llvm-project/tree/main/clang/lib/Driver/ToolChains/.
ToolChain derived classes determine how to construct assembler and linker commands and influence the clang -cc1 command line.

In the past two years, we have received new ToolChain proposals:

  • Hurd (present for a long time with x86-32 support; x86-64 support was new)
  • Managarm
  • SerenityOS
  • UEFI

(Some are stalled due to limited review capacity or testing needs. When I notice new ToolChains, I try to require stricter testing requirements.
)

This post aims to establish a clearer bar for accepting new ToolChains.
In the past, some contributed ToolChains saw little use and were eventually removed (as in ⚙ D158461 [Driver] Remove unlikely-working Minix.cpp and Contiki.cpp).

A similar question was raised by @dblaikie on Managarm ([llvm] Add triples for managarm by no92 ¡ Pull Request #87845 ¡ llvm/llvm-project ¡ GitHub) about the acceptance bar.

I propose that adding a new ToolChain should come with a Discourse proposal (with a clang tag) outlining how the proposed ToolChain meets the criteria listed on Clang - Get Involved (The Clang project uses the following criteria for this evaluation:).
Note that point 3 (“specification”) is not applicable. Driver behaviors don’t have a good specification.

In case of apathy, what shall we do?

(If the author is interested in vendor-impacting decision, consider joining Sign in to GitHub ¡ GitHub .
That said, I suspect that most notifications are likely about diagnostics and unrelated to driver.
)

When the proposal is accepted, the patches should be split to:

  • llvm: e.g. llvm/include/llvm/TargetParser/ llvm/unittests/TargetParser/
  • clang: e.g. clang/lib/Driver, clang/lib/Basic/Targets, clang/test/Driver

The Hurd x86-64 patch #78065 has really good tests that can be used as an example.

I shall also mention ToolChain behaviors can be emulated without upstream code.
If you specify --target=x86_64-unknown-someunknownos, it is like --target=x86_64 and you use the Generic_ELF toolchain.
You can add -I and -L.
You can specify default arguments by customizing x86_64-unknown-someunknownos.cfg beside clang executable,

This can be used for niche ToolChains that are not accepted.

3 Likes
2

@AaronBallman any thoughts on this? Are the “requirements for clang extensions” suitable to generalize/reuse for new toolchains?

3

Thank you for this suggestion! I think it’s a great idea for us to document a policy around how to add new toolchains. I’m not 100% sold on using the criteria for adding extensions to Clang, but that does seem like a reasonable starting point for a policy.

In terms of criteria that I think apply:

  • Evidence of a significant user community
  • A long-term support plan
  • A high-quality implementation
  • A test suite

Criteria that I don’t think apply:

  • A specific need to reside within the Clang tree (I think something like this applies but is covered by “evidence of a significant user community” because that’s really what drives the need for a driver to reside in Clang)
  • A specification
  • Representation within the appropriate governing organization

I think the hard part is evaluating what constitutes “evidence of a significant user community” when it comes to a toolchain. Do we want to come up with some driver-specific criteria related to that?

I think apathy means there’s not evidence of a significant user community in some ways (something with a significant user community should probably have some amount of advocates for it within our community I would guess).

2 Likes
4

I think anything that is supported upstream should come in some binary format pre-built.

When I removed the Ananas support, besides the project being dead I noticed there were never any binary releases. You had to bootstrap build from source from Linux.

I don’t mind helping out and hacking on things. I’ve helped with Solaris, Haiku and other OS’s. There are other commercial OS’s I would consider. But I don’t consider that to be reasonable to support.

1 Like
5

Do you mean, published on the project website? There are toolchains today that don’t do that, and yet have significant-sized user communities. (Sony’s, for instance…)

1 Like
6

Evidence of a significant user community

What counts as ‘significant’?

I think it’s worthwhile to support small(ish -within reason) projects, as long as it’s not causing a significant maintenance burden upstream.

But maybe it would be good to have some kind of dead man’s trigger / inactivity criteria, e.g: ‘if X repo receives no commit in over 1 year, then the project can be assumed dead, and may be removed from LLVM’

1 Like
7

An open source operating system to clarify. It wouldn’t make sense with anything closed source. But they’re still in binary form anyway.

1 Like