27269, "jabraham17", "What LLVM versions can we stop supporting today?", "2025-05-21T23:02:48Z"
As of writing this issue, we currently support a wide range of LLVM versions, LLVM 11 through LLVM 20. This is a lot to maintain and can add considerable burden when developing new features in the backend (e.g. dynamic loading, debug information, etc). How necessary is it maintain these versions?
My stance is that we should preserve enough LLVM versions to maintain maximum compatibility and ease of install. If an OS we support and care about only has LLVM version X, we should support that LLVM version. If that OS is EOL, I think its acceptable for us to say "if you need the latest chapel on this platform, you must use CHPL_LLVM=bundled" (of course if the OS is EOL I don't think we should be under any obligation to support that OS, but that's a separate topic.) We could even go a step further and just require CHPL_LLVM=bundled on some platforms.
I use pkgs.org to check package dependencies, see this for LLVM packages. Based on a cursory look through this, I think we could easily drop LLVM 11, 12, 13, and 14 support. On alinux2 and debian10 (EOL) I think this would require users to use CHPL_LLVM=bundled (or CHPL_LLVM=none), but I think this is an ok tradeoff. This would require updating our prereqs for some OSes. For example, the default llvm package on Ubuntu 22 is LLVM 14, but LLVM 15 is available as llvm-15.
If we drop LLVM 11-14, I would also advocate we turn on opaque pointers for LLVM 15 (on by default in LLVM 16). This would result in a huge cleanup of the code in the backend for LLVM portability