4 ms·
The obvious next step is to make this a JIT. The natural progression of JITs is to start with using llvm for the jit, only to realize that it's too slow and bi
by bla3 7y ago
The obvious next step is to make this a JIT.
The natural progression of JITs is to start with using llvm for the jit, only to realize that it's too slow and big for anything but AoT compilations since llvm is tuned for AoT with clang (and other AoT compilers). So the awkward next step is to add a custom jit to clang for zippy cobstexpr eval because llvm itself doesn't work super well for JITs due to it being tuned for clang's use case. Ironic.
- Asooka 7y agoThere is a jit for exactly this purpose already - libgccjit
- saagarjha 7y agoThis is mentioned, actually: > This project serves mostly as a prototype in order to determine what kind of bytecode and compiler is required to efficiently evaluate code and emit useful diagnostic messages, paving the way for a future fast, potentially JIT-ed, interpreter.
- zamalek 7y agoHold up. The theory (and practice) is that interpreters are superior for code that is only ever executed once, as you don't pay the [relatively high] cost of optimization for a single execution. Unless the most trivial possible JIT is used (one that doesn't optimize at all)?
- comex 7y agoC++ constexpr functions can contain loops and recursion, or just be invoked from multiple locations, leading to the same code being executed more than once.