zlacker

[return to "Zig Libc"]
1. meisel+ya1[view] [source] 2026-02-02 22:45:35
>>ingve+(OP)
> It’s kind of like enabling LTO (Link-Time Optimization) across the libc boundary, except it’s done properly in the frontend instead of too late, in the linker

Why is the linker too late? Is Zig able to do optimizations in the frontend that, e.g., a linker working with LLVM IR is not?

◧◩
2. ibejoe+be1[view] [source] 2026-02-02 22:57:32
>>meisel+ya1
Seems like it ought to be able to do inlining and dead code stripping which, I think, wouldn't be viable at link time against optimized static libraries.
◧◩◪
3. comex+zg1[view] [source] 2026-02-02 23:07:36
>>ibejoe+be1
It is viable against the IR that static libraries contain when LTO is enabled.

LTO essentially means “load the entire compiler backend into the linker and do half of the compilation work at link time”.

It’s a great big hack, but it does work.

◧◩◪◨
4. ibejoe+9j1[view] [source] 2026-02-02 23:18:59
>>comex+zg1
Right, but I think that's what the question of "Why is the linker too late?" is getting at. With zig libc, the compiler can do it, so you don't need fat objects and all that.

---

expanding: so, this means that you can do cross-boundary optimizations without LTO and with pre-built artifacts. I think.

[go to top]