Drop support for LLVM9 #5121
Drop support for LLVM9 #5121
Conversation
|
There's a delay between llvm trunk going to 12 and llvm 11 being released. Our policy is the last two released llvm versions, which I think is currently 9 and 10. |
|
Yeah, no rush to land this (hence the draft status), just wanted to have it ready to go while I was elbow-deep in related stuff |
…0 committer Steven Johnson <srj@google.com> 1594925723 -0700 Drop support for LLVM9 Since LLVM trunk just got bumped to v12, we can consider dropping LLVM9 support. This PR revises the checks for minimum versions to require v10, and removes all conditional code that is no longer required.
steven-johnson
force-pushed
the
srj-llvm9
branch
from
fc5bc3a to
50c4c1d
Compare
|
Can we keep the code needed to support older versions of LLVM for a bit longer ? We're still in the process of upgrading to LLVM 9 for a large part of our codebase, so we're going to need this for a while. |
|
FWIW, this won't go in until the latest llvm release is actually 11, which hasn't happened yet: https://releases.llvm.org/ Trying to think about the cost of supporting old LLVM versions. I think it's:
We could drop testing for llvm one release before deleting the code that uses it I suppose, and that would remove issues 1 and 3 (3 is the truly nasty one). The old llvm might just break slowly over time (but probably not). For the purposes of new code we can ignore the contents of the ifdef... That would give us the schedule: master: supported I'm not sure that's reasonable. That's a lot of llvm versions. Then again I don't think it would cost us much to do. |
|
Given the recent proposal to have Halide releases track LLVM releases, maybe we should start by doing a 'release' for both LLVM9 and LLVM10 (including long-lasting branches for each one, for eg bug fixes). |
|
That makes sense to me. The no_asserts flag being ignored bug that Benoit opened would be the kind of thing we'd backport to old releases. |
|
(...speaking of which, we should probably publicize that plan and see if there are issues that we didn't anticipate.) |
Definitely in favor of that move. Once #5135 lands, this should be quite easy. |
|
LLVM 11 is out. Should we move on this? |
|
Let's see if there is a consensus, and/or a specific timeline we want to wait for |
|
(But since we haven't been testing LLVM9 on the buildbots for a while we probably might as well) |
dependencies/llvm/CMakeLists.txt
Outdated
| @@ -16,7 +16,7 @@ find_package(Clang REQUIRED CONFIG HINTS "${LLVM_DIR}/../clang") | |||
| message(STATUS "Found LLVM ${LLVM_PACKAGE_VERSION}") | |||
| message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}") | |||
|
|
|||
| if (LLVM_PACKAGE_VERSION VERSION_LESS 9.0) | |||
| if (LLVM_PACKAGE_VERSION VERSION_LESS 10.0) | |||
| message(FATAL_ERROR "LLVM version must be 9.0 or newer") | |||
|
tagging @benoitsteiner to comment as he was the last person with a concern |
|
Monday morning ping to @benoitsteiner |
|
No response. Landing. |
Since LLVM trunk just got bumped to v12, we can consider dropping LLVM9 support. This PR revises the checks for minimum versions to require v10, and removes all conditional code that is no longer required.
(Note, this will fail until some buildbot updates are done.)