Track: zig's Mach-O LTO support (revisit -flto on osx-aarch64/osx-x86_64)

[dfa1]

Background

#70 investigated enabling LTO (-flto) in scripts/build-zstd.sh for a compile-time cross-TU inlining win. It works fine on Linux (zig cc links ELF with its bundled real lld), but is currently impossible on macOS:

$ zig cc -target aarch64-macos -O3 -flto -c third_party/zstd/lib/common/xxhash.c -o /tmp/test.o
error: LTO requires using LLD

zig's Mach-O backend is a self-hosted linker, not LLD, so it has no LTO support at all — this reproduces at the -c (compile-only) stage, before any linking. -fuse-ld=lld doesn't help either (no real ld64.lld binary was available to force it).

Separately, even where LTO did work (Linux), the benchmark in #70 showed a net regression on the compress path (zstdJavaBytes -6.2%, zstdJavaSegment -3.7%) versus a smaller decompress gain (+1.9-2.5%) — so LTO was rejected project-wide, not just on macOS. This issue is scoped narrowly to the macOS tooling blocker, in case zig gains Mach-O LTO support and it's ever worth re-benchmarking.

What to watch for

• zig adding LTO support to its self-hosted Mach-O linker, or shipping a real ld64.lld that zig cc -fuse-ld=lld can target on macOS.
• Track via zig release notes / changelog for aarch64-macos and x86_64-macos linker work.

Revisit when

If Mach-O LTO becomes available via zig cc:

1. Re-run the same -flto experiment from Optimize the native build #70 on osx-aarch64/osx-x86_64.
2. Re-benchmark compress/decompress (JMH, benchmark-lto.yml) — the Linux result (compress regression, decompress gain) may or may not hold on ARM/Mach-O codegen, so don't assume the same disposition applies.

No action needed until then; this issue exists purely to remember to check back.