Open radl97 opened 3 years ago
It seems that there is a widely used class (Immutable)CallSite
(present in e.g. SpecialFunctions), which I haven't seen in LLVM11. It seems there is an alternative AbstractCallSite (present at both), but it seems to work semantically different (It needs a Use*
for constructor). Another alternative is to use CallBase*
, because it is the underlying structure. The good news is that it exists even in LLVM9, so these changes do not break LLVM9 build process (probably).
There are also many CreateCall instructions which were deprecated in LLVM9, but these can be fixed easily.
Note that there are some breaking changes (e.g. InlineFunction
and its feasibility check returns InlineResult
instead of bool, without an operator bool()
defined).
So I haven't been able to create a code that compiles in LLVM-11, but it seems feasible, but there could be many changes here and there.
Thanks for raising this point. Indeed, it would make sense to upgrade eventually: installing old LLVM versions just for Gazer is definately not fun. Now this raises another interesting question: how do we want to keep ourselves up-to-date with the newer LLVM versions. There are multiple points to consider:
clang
and llvm-link
? If there is an incompatibility on the LLVM IR format between the versions, the translation process can break. My take on the first two points is that we should not try to support multiple things at once. In the case of an update of 9 -> 11
I would upgrade the required clang/llvm-link
version to 11, and clang-9
/llvm-link-9
could be supported as best-effort. Also I think it would make sense to tie ourselves to the policy of Ubuntu packages, either the LLVM version in the current Ubuntu stable or the current Ubuntu LTS. What do you think?
As an answer/reinforcement to the last comment:
I completely agree with upgrading everything to 11. About the best-effort support: I'm not sure, if that's necessary(?), in what case/on what system would anyone want to use llvm 9 on purpose instead of 11, do you know anything, that would require this?
I think, upgrading periodically is more than enough. Tying ourselves to the current Ubuntu LTS packages seems like a nice balance between not having to work constantly on LLVM upgrades, but still providing an easy-to-use/easy-to-install solution.
And I think right around now is a good time to upgrade: Ubuntu 20.04 is getting wide-spread; as it was mentioned, other distros (Arch) are getting problematic - these look like perfect signs for an upgrade.
Another small memo: If we are going with this, let's upgrade everything to 20.04 - the CI is already running on that, but the Docker is still 18.04 (it's easy to upgrade though).
Thanks for your input. Then LLVM 11 it is.
There is already a patch for this. There are still TODOs, but it will be ready in no time: Upgrade to 20.04, require LLVM11 (instead of 9), and I'll iterate through some API changes...
There is one that comes to my mind: -inline
flag collides in some tool that I want to use (LLVM's testing utility opt
), so I'm planning to rename it to -inline-level
. I'll add it to the PR itself.
EDIT: Reworded.
Note that the LLVM version in the current Ubuntu LTS (20.04, focal) is LLVM 10: https://packages.ubuntu.com/focal/llvm. So if we are doing Ubuntu LTS, then it's either 10 or we will be in sync with Ubuntu stable (20.10, groovy).
As "best effort support" I meant that if it works, good, but no extra effort from our side to support it :)
As for "what system would anyone want to use llvm 9 on purpose instead of 11": there is a difference between the development environment and the LLVM version we use to develop the project and the environment in which it will be ran. This is not an apparent issue now as everyone who runs Gazer needs to compile the distributed sources. However, if we start distributing binaries (which I hope we will at one point), this is a point to take into consideration. Upgrading compilers is not always desirable and certain distributions (e.g. Debian) lag behind quite a bit on the LLVM/Clang versions.
As for the other possible breaking changes: I have a couple of things in mind, such as upgrading the supported Boost version and removing some stuff which do not work well in the current pipeline. I will open tickets about these and tag them with a gazer-2.0
milestone.
Someone mentioned that we could upgrade LLVM framework (current version is 9). There are many different aspects to this, so I think it is useful to start a discussion to even consider using this.
On the pro side, I think newer versions might have
On the con side, we should consider what changes will it cost. I haven't yet done any research. But this might mean
extract-value
which are very specific and only helpful for lowering to machine code), orOne might even consider creating LLVM version-independent code (I did not find anything in the LLVM documentations that were changed across 9.0 and latest. This might mean it just works with any LLVM). Note that the code is independent, but I'm not speaking of binary-compatibility.
What are your thoughts?
@AdamZsofi and @sallaigy (if you have time).