Legacy LLVM Version Removal #305146
Comments
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/legacy-llvm-version-removal/43666/1 |
|
The plan for Darwin going forward is to do annual updates to whatever is the latest after the x.05 release. The goal is not to be stuck on the trailing edge of LLVM support as Darwin was in the past. |
|
Been told Haskell's latest supported LLVM version is 16. |
|
Note that there are multiple versions of GHC in Nixpkgs but I don't know whether they're maintained to any official capacity. cc @sternenseemann @cdepillabout As for maintenance: Would it perhaps be possible to bundle older versions of LLVM into a legacy derivation that is "maintained" (or rather not maintained very much) separately from the primary derivation for modern LLVM? Or simply keep the separate files for the old versions that we currently have and only integrate modern versions into the new generic derivation. That way we could have a modern and maintainable LLVM drv while those depending on older versions of LLVM could still use the legacy derivations. They wouldn't be improved in any way but they will likely just continue working as they always have. |
Alternatively, we could add a warning saying that the LLVM version is deprecated. Once every package is moved away from that version, we can remove it.
They do not require much. However after the commonification PR's, every subpackage gets a common Nix file. This means there's a lot of version checks. If we're able to deprecate certain versions then we can remove those specific version checks. This would be less evaluation and less code to manage overall. My concern is unnecessary rebuilds and ending up with Nix files that have a ton of version checks. |
|
cc all of @NixOS/haskell for the ghc/llvm stuff |
If that's the only concern, the option I described would also be sufficient; keep the old versions in separate files as they are right now and only attempt to commonise the latest versions. The legacy versions won't get any of the improvements of the common drv but they're legacy anyways so nobody expects them to improve or change in any way. |
|
One thing I forgot to mention is that my intention is merely to present this idea as an alternative because it didn't seem to have been considered. I'm only slightly in favour of it and don't have a horse in this race; if you think that's not feasible, that's completely fine by me. The reason I'm slightly in favour is just that IME having old versions around can be really valuable at times, so I generally like keeping stuff for as long as it doesn't cause an actual maintenance burden. |
|
GCC in nixpkgs supports all the way back to 4.8. Is there anything it’s doing that might be useful for LLVM? It has many version checks, but there are helpers to make them nicer to use. |
The commonification of LLVM is already done and I don't want to split things up into a legacy set of things because of redundancy.
Yeah, though people can import older versions of Nixpkgs if they really want an ancient version of a package. Anything critical to Nixpkgs, we can do extra stuff for if they really need to be on an old version of LLVM.
As GCC is needed for literally everything in Nixpkgs, I think that GCC having versions that old makes sense. However, LLVM does not have as many dependent packages. |
But would how it does that be useful or applicable to LLVM? That’s why I brought it up. If the preference is not to maintain older version support regardless, that’s understandable. |
I'm not sure how GCC is in Nixpkgs, depending on how it is set up then I might prefer going that route. |
tomodachi94
added
the
6.topic: old-versions
lf-
added
the
6.topic: llvm/clang
|
Note that old LLDB versions are soon going to be one of the few things keeping SWIG 3 around, although it would probably be reasonable to support fewer LLDB versions than LLVM versions. |
|
I think at this point, it would be good to track the dependents on LLVM for each version. Then find which has the least amount of dependents, we can probably work from there to track which versions should have work done to be removed and which ones should be deprecated. Ideally, we should have like supported 5 in total (excluding git). |
|
Had a discussion with @maralorn & @emilazy on the subject of LLVM 12 and GHC. It seems GHC 9.6 is recommended and GHC 9.4.5 could theoretically be bumped to LLVM 13. Been thinking of adding a warning to LLVM 12 for NixOS 24.05 that it will be up for removal and so packages should move away from using it unless we can find any other valid reason to keep it. Imo, if someone wants to use LLVM 12 or a GHC version which depends on LLVM 12 then they should just pull in an old nixpkgs version. 24.05 would be the last without the warning and is in a pretty good state. So any objections to adding a deprecation warning or should we still keep LLVM 11 around? If we still want to keep it around, how long should we keep it for? |
|
Can you clarify to me what the problem is with LLVM 12? I assume the common expression reduces the amount of work it takes to maintain it. In what way does LLVM 12 cause extra work? Build time on Hydra for LLVM is not that bad in my experience (in fact the intermediate GHC versions like 9.4.5 we have and need to find a way to get rid of are much worse) and given that just GHC depends on it, I'm completely okay if less scrutiny is applied when testing changes w.r.t. LLVM 12.
GHC 9.4.* officially supports up to LLVM 14. All GHC versions earlier than that already use the maximum officially supported LLVM version (12). |
LLVM 12 is pre monorepo, it'll be great to remove the expressions which handle that check. We also have every version of LLVM from 12 to 20 (git) so that's 8. How many LLVM versions do we want to keep around? Do we really need 8 versions or would we eventually keep 20 versions of LLVM by the time LLVM 40 is around and still keep 12 around? It'll be great to remove old version checks as well, makes things more readable. Another reason why LLVM 12 should be removed is because if we remove stuff, it should be done in order of version and 12 is currently the oldest one. |
I see no reason why holes between versions can't be a thing in multi-version packages. In the ffmpeg package, we had ffmpeg 4, 5, 6 and 7 a little while ago. The first removed version was 5 and the next one will be 6 because 4 is still used by some legacy and proprietary packages that cannot easily be upgraded to 7. The fact that LLVM 12 uses different repo structure makes it annoying though and is a much better reason for removing it. Perhaps an exception could be made for LLVM 12 specifically to keep a copy of the legacy expression with the intention that it'll be removed once the dependant GHC versions are gone/deprecated. Obviously any future refactors or improvement would not be ported to the legacy expression but that should be fine for GHC's use-case. |
More of a preference. Imo, easier to say something like 15 - 19 versus listing a bunch of ranges. It probably might make it a bit more manageable and less chaotic to remove in order when we have things using the version check guards.
From what I've heard, it sounds like we could just remove LLVM from GHC. That's what Gentoo does and they seem to be doing fine with it. I also heard they've only got 3 versions, I'm not sure why we need 8. We've also got 31 total consumers between LLVM 12, 13, 14, & 15 based on the result from this command: I asked about a version support policy on LLVM's Discord server:
Probably good to keep this in mind. Obviously, it would be a lot of work to keep around only a few versions. However, it sounds like pretty much anything before 17 isn't really worth using. Based on this, I think we shouldn't just remove 12 but anything before 17 or at least up to 15. |
|
With #348568, the LLVM 12 specific expression can be removed, so we'd have a single expression for all LLVM versions. Removing an LLVM version would then only get rid of a few conditionals (which I'm confident we can simplify even more) and custom patches. That should ease the pain of carrying around LLVM 12 until we can remove it and GHC 8.10.7-9.2.8 (or we find another solution). |
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually
|
Below is the LLVM (official) support table for GHC.
Looks like GHC 9.12.1 will support LLVM 18. |
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually
Breaking aarch64 support doesn't sound fun, idk what I use on aarch64-linux myself or others that relies on GHC 8.10 but it still probably hurts. |
|
There’s little that uses GHC 8.10 in the Nixpkgs tree and all such packages can probably be dealt with; see #346214. It was discussed by I think @alexfmpe that the LLVM backend doesn’t change much and has very conservative version bounds that are unlikely to be necessary given its use of the textual IR format, i.e. it’s not really that there’s extensive LLVM‐upgrading work being done to increase the bounds in alter versions. I think weakening the upper bound, which is something we do for many dependencies across the tree already, is a reasonable option to consider if we want to continue offering GHC 8.10 to AArch64 users. |
That's reassuring at least. |
|
Ah, it was actually @angerman who said this:
|
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually - On Darwin, we need to bypass CMake's C++ compiler for libcxx and libunwind now. It isn't a 100% clear why, probably because we've started to use Darwin's bootstrapStdenv for libcxx in the common expression compared to LLVM 12 on master [1]. The reordering of flags for wasm causes a rebuild for some packages like firefox, but this should be tolerable on staging. [1]: https://github.com/NixOS/nixpkgs/blob/665ebfb253caba7b85c2affefe2a92b305def4e6/pkgs/development/compilers/llvm/12/default.nix#L392-L430
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually - On Darwin, we need to bypass CMake's C++ compiler for libcxx and libunwind now. It isn't a 100% clear why, probably because we've started to use Darwin's bootstrapStdenv for libcxx in the common expression compared to LLVM 12 on master [1]. The reordering of flags for wasm causes a rebuild for some packages like firefox, but this should be tolerable on staging. [1]: https://github.com/NixOS/nixpkgs/blob/665ebfb253caba7b85c2affefe2a92b305def4e6/pkgs/development/compilers/llvm/12/default.nix#L392-L430
As mentioned in #305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With #347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually - On Darwin, we need to bypass CMake's C++ compiler for libcxx and libunwind now. It isn't a 100% clear why, probably because we've started to use Darwin's bootstrapStdenv for libcxx in the common expression compared to LLVM 12 on master [1]. The reordering of flags for wasm causes a rebuild for some packages like firefox, but this should be tolerable on staging. [1]: https://github.com/NixOS/nixpkgs/blob/665ebfb253caba7b85c2affefe2a92b305def4e6/pkgs/development/compilers/llvm/12/default.nix#L392-L430 (cherry picked from commit ee9eacf)
As mentioned in #305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With #347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually - On Darwin, we need to bypass CMake's C++ compiler for libcxx and libunwind now. It isn't a 100% clear why, probably because we've started to use Darwin's bootstrapStdenv for libcxx in the common expression compared to LLVM 12 on master [1]. The reordering of flags for wasm causes a rebuild for some packages like firefox, but this should be tolerable on staging. [1]: https://github.com/NixOS/nixpkgs/blob/665ebfb253caba7b85c2affefe2a92b305def4e6/pkgs/development/compilers/llvm/12/default.nix#L392-L430 (cherry picked from commit ee9eacf) (cherry picked from commit c4e9f17)
As mentioned in NixOS#305146, keeping LLVM 12 is a source of pain because it is the only version to be built from individual release tarball instead of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo as well, simplifying all common LLVM expressions in the process. With NixOS#347887, some quirks in the expressions for LLVM <14 were ironed out, so building LLVM through from the monorepo is quite simple now. - Most expressions only required minor changes, mostly removing the special casing for `sourceRoot`. - The patch lists from llvm/12/default.nix were ported to common/default.nix. This only required a few extra conditionals which could be reduced via a rebuild also involving other LLVM versions. Outstanding tasks of little urgency have been noted in TODO comments. I have verified that the patch lists stay the same for all packages except LLVM where merely the order changes. An extra set of eyes is appreciated, of course. - clang: The expression was reworked to use the same symlink location for clang-tools-extra for all versions including LLVM 12. This required adjusting the ad hoc patching of the clangd cmake files slightly. - libunwind: We no longer need to make the libcxx sources available manually. We can rely on the monorepo source instead. - lld: We no longer need to make the libunwind sources available manually. - llvm: We no longer need to make the polly sources available manually - On Darwin, we need to bypass CMake's C++ compiler for libcxx and libunwind now. It isn't a 100% clear why, probably because we've started to use Darwin's bootstrapStdenv for libcxx in the common expression compared to LLVM 12 on master [1]. The reordering of flags for wasm causes a rebuild for some packages like firefox, but this should be tolerable on staging. [1]: https://github.com/NixOS/nixpkgs/blob/665ebfb253caba7b85c2affefe2a92b305def4e6/pkgs/development/compilers/llvm/12/default.nix#L392-L430 (cherry picked from commit ee9eacf) (cherry picked from commit c4e9f17)
|
With #378713 being opened, we'll have 10 LLVM versions. I want us to continue this effort of trimming LLVM versions. Especially with the goal of getting a version which should depend on zero patches. If we can drop old versions, we can remove some patches and start trimming certain things which are applied based on the version. |
|
After #379365, bootstrapping GHC >= 9.6 should no longer erroneously pull in LLVM 12 on aarch64. While the binary GHC 9.2.4 still nominally takes LLVM 12 as an input, it is disabled for all architectures we have it packaged for (x86_64, i686, aarch64). This should solve the problem @emilazy was seeing that LLVM 12 regressions immediately caused all of |
As new versions of LLVM come out and get packaged, the amount of LLVM versions we have in Nixpkgs grows. This means more maintenance and work to upkeep older versions. However, if we were to cap the number of LLVM versions we would support then this would mean less work. Though there are challenges as many different things in Nixpkgs depends on different LLVM versions. At the time of writing, we have versions 12, 13, 14, 15, 16, 17, 18, and the git versions. Git will never be removed as it is essentially a testbed for new versions and I use it for proactively updating. LLVM 19 comes out some time in June according to their tracker. When 19 comes out, we would have 8 specific versions of LLVM.
This issue will open the discussions on figuring out the proper procedures of removing legacy versions of LLVM.
The text was updated successfully, but these errors were encountered: