3 ms·
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 f
by alexnask 6y ago
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 :))
- nick_ 6y agoVery 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.
- theresistor 6y agoLLVM's interpreter is atrociously slow. It's only really meant for debugging LLVM itself.