Comments (5)
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:
- 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
andllvm-link
? If there is an incompatibility on the LLVM IR format between the versions, the translation process can break. - 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?
- 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?
from gazer.
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.
- 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).
from gazer.
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.
from gazer.
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.
from gazer.
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.
from gazer.
Related Issues (20)
- Jumping out of a loop from two different blocks to a same exit block breaks the translation of PHI values
- Basic format of the configuration description HOT 2
- Portfolio script as entry point of the docker file HOT 1
- Move CI to GH Actions
- Segmentation fault in a program with return in a nested loop
- Test harnesses should mock unused functions
- Support SV-COMP ReachSafety-Arrays with BMC HOT 1
- Support SV-COMP ReachSafety-Arrays with Theta
- Support SV-COMP ReachSafety-BitVectors with Theta
- Support SV-COMP ReachSafety-Floats with Theta
- Support SV-COMP ReachSafety-Heap with BMC HOT 2
- Support SV-COMP ReachSafety-Heap with Theta HOT 1
- Support SV-COMP ReachSafety-Sequentialized with BMC HOT 1
- Support SV-COMP ReachSafety-Sequentialized with Theta HOT 1
- Support SV-COMP ReachSafety-Combinations with Theta
- Support SV-COMP ReachSafety-Combined with BMC HOT 1
- Support 'malloc' in flat memory model
- Gitignore for portfolio HOT 3
- Test Docker image with GH Actions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gazer.