Re: Guiding principle for dropping LLVM versions?
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Xing Guo <higuoxing@gmail.com>, Devrim Gündüz <devrim@gunduz.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-10-25T05:47:20Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
jit: Require at least LLVM 14, if enabled.
- 972c2cd2882b 18.0 landed
-
jit: Require at least LLVM 10.
- 820b5af73dcc 17.0 landed
Attachments
- v4-0001-jit-Require-at-least-LLVM-10.patch (text/x-patch) patch v4-0001
Here are some systematic rules I'd like to propose to anchor this
stuff to reality and avoid future doubt and litigation:
1. Build farm animals testing LLVM determine the set of OSes and LLVM
versions we consider.
2. We exclude OSes that will be out of full vendor support when a
release ships.
3. We exclude OSes that don't bless an LLVM release (eg macOS running
an arbitrarily picked version), and animals running only to cover
ancient LLVM compiled from source for coverage (Andres's sid
menagerie).
By these rules we can't require LLVM 14 for another year, because
Ubuntu and Amazon Linux are standing in the way*:
animal | arch | llvm_version | os | os_release | end_of_support
---------------+---------+--------------+--------+------------+----------------
branta | s390x | 10.0.0 | Ubuntu | 20.04 | 2025-04-01
splitfin | aarch64 | 10.0.0 | Ubuntu | 20.04 | 2025-04-01
urutau | s390x | 10.0.0 | Ubuntu | 20.04 | 2025-04-01
massasauga | aarch64 | 11.1.0 | Amazon | 2 | 2025-06-30
snakefly | aarch64 | 11.1.0 | Amazon | 2 | 2025-06-30
sarus | s390x | 14.0.0 | Ubuntu | 22.04 | 2027-06-01
shiner | aarch64 | 14.0.0 | Ubuntu | 22.04 | 2027-06-01
turbot | aarch64 | 14.0.0 | Ubuntu | 22.04 | 2027-06-01
lora | s390x | 15.0.7 | RHEL | 9 | 2027-05-31
mamushi | s390x | 15.0.7 | RHEL | 9 | 2027-05-31
nicator | ppc64le | 15.0.7 | Alma | 9 | 2027-05-31
oystercatcher | aarch64 | 15.0.7 | Alma | 9 | 2027-05-31
Ideally more distros would be present in this vacuum-horizon decision
table, but I don't think it'd change the conclusion: 10 is the
trailing edge. Therefore the attached patch scales back its ambition
to that release. Tested on LLVM 10-18.
If I pushed this we'd need to disable or upgrade the following to
avoid failure in configure on master:
animal | arch | llvm_version | os | os_release
| end_of_support
-------------+--------------------+--------------+--------+------------+----------------
dragonet | x86_64 | 3.9.1 | Debian | sid |
phycodurus | x86_64 | 3.9.1 | Debian | sid |
desmoxytes | x86_64 | 4.0.1 | Debian | sid |
petalura | x86_64 | 4.0.1 | Debian | sid |
mantid | x86_64 | 5.0.1 | CentOS | 7
| 2019-08-06
idiacanthus | x86_64 | 5.0.2 | Debian | sid |
pogona | x86_64 | 5.0.2 | Debian | sid |
cotinga | s390x | 6.0.0 | Ubuntu | 18.04
| 2023-06-01
vimba | aarch64 | 6.0.0 | Ubuntu | 18.04
| 2023-06-01
komodoensis | x86_64 | 6.0.1 | Debian | sid |
topminnow | mips64el; -mabi=32 | 6.0.1 | Debian | 8
| 2018-06-17
xenodermus | x86_64 | 6.0.1 | Debian | sid |
alimoche | aarch64 | 7.0.1 | Debian | 10
| 2022-09-10
blackneck | aarch64 | 7.0.1 | Debian | 10
| 2022-09-10
bonito | ppc64le | 7.0.1 | Fedora | 29
| 2019-11-26
*Some distros announce EOL date by month without saying which day, so
in my data collecting operation I just punched in the first of the
month, *shrug*