Discussion: Upgrading LLVM framework?

[radl97]

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

• newer passes added,
• Passes are better optimized,
• Modern C++ versions are probably better supported.
• Easier install... Most Linux distributions have moved to newer versions of LLVM, and older versions are hard to wire to the system. (More so, if one wants to install other LLVM-based tools). For example ArchLinux users have a hard time installing the old LLVM, but it is possible nonetheless.

On the con side, we should consider what changes will it cost. I haven't yet done any research. But this might mean

• handling new instruction, if any (thinking of instructions like extract-value which are very specific and only helpful for lowering to machine code), or
• Some feature API changed (We are already using a legacy pass manager... It could be that it was removed).

One 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).

[radl97]

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.

[sallaigy]

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:

1. If we upgrade the underlying library to a newer version, do we also want to update the minimum requirement on the tools the translation process invokes, such as clang and llvm-link? If there is an incompatibility on the LLVM IR format between the versions, the translation process can break.
2. What do we consider as the desirable supported LLVM version? Do we want to be on the bleeding edge or just upgrade periodically? How do we know that it is time to upgrade?
3. This is a bit technical, but as changing the required LLVM version also changes functionality, the major version number should be upgraded - a good opportunity to introduce other breaking changes within Gazer.

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?

[AdamZsofi]

As an answer/reinforcement to the last comment:

1. 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?

2. 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.

3. I agree again, good idea, let's introduce Gazer 2. But what other breaking changes to introduce, is there such a feature or idea in progress right now?

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).

[radl97]

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.

[sallaigy]

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.