Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks, that's the answer to my question :) Do you know if there has been any plans to implement this build-time optimization upstream in LLVM itself? Perhaps after it's been completed within Zig.


While I am not terribly familiar with the LLVM codebase, this kind of improvement would probably require massive internal changes.

One example of this is the fact that codegen needs to be aware of the linker to emit correct code depending on the type of executable that is being generated, since different strategies can and are used for different formats (for example, currently the x86_64 backend will generate different instructions for function calls on ELF and PE/COFF vs MachO).

I would totally get behind LLVM or other compiler toolchains working towards this kind of functionality, but this is hardly something Zig developers could implement in a massive project such as LLVM (which is precisely why we are building our own :))


Very interesting. It makes a lot of sense. Do you have a read on how well using the LLVM interpreter modes fill this gap?

EDIT: To be clear, I mean the gap of slow build performance in the feedback look of code-build-check.


LLVM's interpreter is atrociously slow. It's only really meant for debugging LLVM itself.


We started looking at build times of the Linux kernel with Clang this summer. Turns out that compile times are dominated by Clang, not LLVM. Sounds like different experiences for different frontends.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: