[cfe-dev] [RFC] ConstExprPreter — clang constexpr interpreter

[JF Bastien via cfe-dev]

> On Jul 4, 2019, at 8:31 AM, Nandor Licker via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Hello David,
> 
>> Can you contrast your approach with the other proposal that's come up a few times of simply JITing the constexpr bits of the code using the existing compiler infrastructure?
> 
> A JIT could be the next step following the interpreter, if the cost of the JIT can pay for itself.
> Unfortunately, given the way the current evaluator is implemented, we cannot just go for
> "simply JITing the constexpr bits of the code": a more fine-grained value representation and
> a better pointer representation is needed, as well as a mechanism to manage and link
> all the constexpr functions and methods in a compilation unit. We develop these in the
> context of a bytecode interpreter. 

I agree that a JIT is purely additive to Nandor’s approach. You need to do all the same work as Nandor proposes, and then a lot more for the JIT to work. If JIT-compilation is the only support mechanism then some platforms that can’t JIT won’t even be able to compile.

I really want to stress one point Nandor makes: the JIT has to pay for itself in runtime. His approach has a handful of optimizations that pay for themselves, and he still requires really simple tree interpretation because an interpreter costs too much for extremely simple expressions. Writing a JIT is a balance between compile-time and runtime performance, and if you want both you end up with tiering, and eventually you have an interpreter anyways.

A JIT is therefore something to keep in mind, but definitely not something to prioritize. It’ll only start making sense *if* people start writing extremely complex constexpr code. If that happens, the interpreter is the right starting point.