processor: match pkgimage and base image vector width exactly
When a sysimage is loaded, `match_sysimg_target` clamps the JIT target down to
the vector width of the matched sysimage clone, stripping AVX/AVX-512 features.
This is required for ABI correctness: on x86 the vector width determines how
`VecElement` tuples are passed in registers (xmm/ymm/zmm), so code that calls
between images must agree on the vector width.
Package images must therefore use the *same* vector width as the base image
they link into, but neither side enforced this:
- Build side: the precompile worker was launched with the raw `-C` target
(typically `native`), and `jl_get_llvm_clone_targets` re-resolved it from
scratch to the full host width, ignoring the sysimage it was building
against. On a host wider than the sysimage (e.g. an AVX-512 machine running a
sysimage built for a narrower target), it emitted an AVX-512 pkgimage that no
longer matched the clamped JIT, failing to load with "Unable to find
compatible target in cached code image" right after a successful precompile.
- Load side: `match_targets` only rejects clones that require features the JIT
has disabled (an upper bound); it otherwise selects the widest compatible
clone, with no lower bound. Since the pkgimage cache is keyed by the
cpu_target string and not the sysimage's vector width, a pkgimage built
against a narrow base could later be selected for a wider base, silently
loading code with a mismatched calling convention.
Fix both ends. Factor the feature-clamping logic into a shared
`clamp_vector_features` helper and apply it to the pkgimage clone targets in
`jl_get_llvm_clone_targets` (guarded on `jl_options.incremental` so full
sysimage builds keep their complete multi-versioned target set), so the worker
builds a clone at the base image's width. Then, in `match_pkgimg_target`,
reject any pkgimage whose matched clone's vector width does not equal the base
image's, forcing recompilation at the correct width rather than loading a
mismatched image.
This pull request was written with the assistance of generative AI.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
