Update LLVM libraries from v22 to v23 #27992

Activity

1. arsnyder16 commented on Oct 16, 2026

   

   arsnyder16

   on Oct 16, 2026

   Contributor

   More actions

   These were also 21-to 22
   #27374
   #27246
2. arsnyder16 commented on Oct 16, 2026

   

   arsnyder16

   on Oct 16, 2026

   Contributor

   More actions

   Is there any reason to hold #27808?

   The current approach seems a little unusual: the compiler and related tools track LLVM tip-of-tree, while libraries such as compiler-rt are synchronized periodically with stable LLVM releases. As #27223 demonstrates, allowing compiler-rt to fall behind the compiler can create incompatibilities.

   At the same time, there appears to be a preference for updating all of the LLVM libraries together, even though each library has its own update process, and PR. Treating them separately while still trying to keep them synchronized seems to create a fair amount of coordination and maintenance overhead.

   The current stable-release policy and its update mechanics are documented, but #27223 raises an unresolved question about whether compiler-rt can continue following that cadence. It is also unclear whether the LLVM runtime updates should remain separate processes when they are generally intended to move together.

   The simpler models, from my perspective, would be either:

   1. Everything sourced from llvm-project tracks tip-of-tree.
   2. Everything sourced from llvm-project is pinned to the same stable release.

   I understand why tip-of-tree makes sense for the compiler and related tools, but many of those same reasons seem applicable to the runtime libraries as well. If the libraries are expected to move together, it may also be worth considering whether they should share a single update and tracking process rather than being managed independently.
3. sbc100 commented on Oct 16, 2026

   

   sbc100

   on Oct 16, 2026

   CollaboratorAuthor

   More actions

   I think this tip-of-tree argument makes sense for compiler-rt (which is why I opened #27223).

   I'm not so sure about the other libraries. Updating them constantly would add a significant mananance burden and I'm not sure I want to be the project that gets all tip-of-tree libc++ issues, for example. I'd rather not be exposed to the day-to-day breakages in libc++ like we are for the compiler itself (those are bad enough already).
4. aheejin

   self-assigned this

   on Oct 19, 2026