* ci: build the compiler image on a prebuilt LLVM image
The Docker workflow built LLVM as the first stages of the compiler image. The
only thing that prevented a rebuild was the BuildKit registry layer cache. A
layer cache is a best-effort optimisation, so CI sometimes built LLVM again
although llvm-version.txt did not change.
Move the LLVM stages to Dockerfile.llvm and make the compiler image start from
that image through an LLVM_IMAGE build argument. The compiler build now holds
no LLVM build step, so it cannot build LLVM again.
Tag the LLVM image with the LLVM revision and a hash of the files that set the
content of the image: llvm-version.txt, Dockerfile.llvm, GNUmakefile, and the
files in make/. tools/llvm-image-tag.sh prints the tag, and CI and developers
use the same script. The workflow builds and pushes the LLVM image only when
the registry does not hold that tag.
Remove the object files and the git history from the LLVM image in the same
layer as the build. The CI caches already link against that subset, see
.github/actions/setup-llvm/action.yml.
Delete llvm.yml. It made an image that nothing used, and it needed a push to a
special branch. The Docker workflow now does the same work when it is
necessary, and the force-llvm input of the manual trigger makes the image
again.
The LLVM image goes to GHCR only, because only CI uses it. The compiler image
continues to go to Docker Hub and GHCR.
* ci: remove the LLVM git history in the layer that makes it
The removal was in the tinygo-llvm-build stage. This stage is below the
layer that makes the shallow clone. A later layer only hides files from a
parent layer. Thus the pack files stayed in the published image.
* ci: link the LLVM image to the repository
The label puts the package in the repository package list, so the package
settings are easy to find. BUILDING.md now tells you to build LLVM locally
if you are not able to pull the image.
The Actions cache of the repository was at 10.24 GB against a quota of
10 GB, so GitHub removed entries by least recent use. The LLVM entries
were among the first to go, and CI then built LLVM again although the
LLVM version did not change.
The Docker buildx layer blobs held 6.0 GB of the quota. All LLVM caches
together held 1.97 GB. Move the Docker layer cache to a registry cache in
GHCR, which does not use the Actions quota. Both jobs have the necessary
permission and login already.
Pin the LLVM commit in llvm-version.txt and fetch that commit, in place
of a clone of the branch tip tinygo_22.x. Add a hash of that file to each
LLVM cache key, so a change of the LLVM version invalidates the caches
and no other change does.
Also rename the LLVM image tags from llvm-20 to llvm-22.
Now that the drivers repo and friends are intended to target the most
recent release version of TinyGo instead of the development version,
this trigger does not serve any puppose to trigger a build that will have
already been tested.
Signed-off-by: deadprogram <ron@hybridgroup.com>
This commit adds support for LLVM 16 and switches to it by default. That
means three LLVM versions are supported at the same time: LLVM 14, 15,
and 16.
This commit includes work by QuLogic:
* Part of this work was based on a PR by QuLogic:
https://github.com/tinygo-org/tinygo/pull/3649
But I also had parts of this already implemented in an old branch I
already made for LLVM 16.
* QuLogic also provided a CGo fix here, which is also incorporated in
this commit:
https://github.com/tinygo-org/tinygo/pull/3869
The difference with the original PR by QuLogic is that this commit is
more complete:
* It switches to LLVM 16 by default.
* It updates some things to also make it work with a self-built LLVM.
* It fixes the CGo bug in a slightly different way, and also fixes
another one not included in the original PR.
* It does not keep compiler tests passing on older LLVM versions. I
have found this to be quite burdensome and therefore don't generally
do this - the smoke tests should hopefully catch most regressions.
Ron Evans
Ayke van Laethem
Austin Vazquez
Yurii Soldak