ConstExprPreter – Clang Constexpr Interpreter | Hacker News Reader

ConstExprPreter – Clang Constexpr Interpreter

lists.llvm.org

64 pointsgbrown_23 comments

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.

There is a jit for exactly this purpose already - libgccjit

Nonsense. gcc constexpr are totally broken (at least in C, C++ not so, compared to LLVM), llvm has a much better jit than gcc's, and llvm would not touch GPL with a ten foot pole.

Well, given that ISO C doesn't say anything about constexpr....

This 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.

Hold 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)?

C++ constexpr functions can contain loops and recursion, or just be invoked from multiple locations, leading to the same code being executed more than once.

I like this work and their approach but there is a third risk (in addition to the two they mention) which is the risk of skew in the compile time and runtime interpretation of certain constructs.

Obviously when this happens it's a bug; the real question is "if such a bug occurs (i.e. the semantics of the program is affected by the use of constexpr) will it confuse the developer?"

Lisps (which have always intermixed interpreted and compiled code as long as lisp compilers have existed) have often struggled with this problem even though they have in many ways a simpler problem to address.

And since I'm writing about C++: I really love c++ but I hate the keyword "constexpr" as it's actually "const_statement". the distinction between statements and expressions, and the concomitant problem that expressions aren't first class, is a c-inherited botch on the language IMHO.

Edit: s/similar/simpler/

That risk has nothing to do with this work. That's an inherent risk with compile time evaluation.

C++ defines constant evaluation to be the same as normal evaluation, although C++20 is adding a way to tell when you're evaluating at compile time so you can avoid things like inline asm at compile time.

constexpr doesn't even mean const_statement. All it means is don't emit an error if constant evaluation calls this function.

I thought constexpr implies const: https://godbolt.org/z/u3a1pq

That is what bothers me about constexpr. It conflates compile-time evaluation with non-mutability. I want a keyword that guarantees an evaluation happens at compile-time, but doesn't by itself imply "const".

Yeah, on variable decls it does indeed mean const. It also means inline on functions and static data members (but not global variables).

I'm not even sure what that would mean since the machinery to compute the value won't exist in the binary.

You can get this behavior by initializing a variable with the value of another variable whose value is a constexpr. This is a case in which the order of initialization of global variables is not ambiguous!

    constexpr int foo_init_value = 2 + 4;
    int foo = foo_init_value;

Actually not a bad idiom.

But like you I do wish you could apply constexpr-like behavior to expressions rather than just statements:

What you're If you could really apply really applied to expressions you could write something like

    int foo = _compute_at_compile_time(2 + 4);

Of course the compiler can already do this degenerate example for you.

The first example is handled by constinit (or whatever we end up calling it) and the second is handled by consteval, although it has to be put in a function.

It doesn't even guarantee compile-time evaluation; it only guarantees that it can be evaluated at compile time. There is no guarantee for the compiler to actually do so --and some compilers will barf on complex constexpr. Future editions of C++ add consteval to ensure that it is evaluated at compile time.

Does real-world code loops so much in constexpr code that optimizing its evaluation is worth it?

If so, why invent another bytecode to do the evaluation, with the risk of introducing inconsistencies? Couldn’t they add a flag “must be fully constant folded” to the compiler intermediate code, and, if (likely) necessary, optimize the LLVM constant folding optimization passes?

As a bonus, that could help other languages with a LLVM backend that want to do similar stuff.

You cannot use memcpy in constant expressions so you have to iterate by hand for copying.

constexpr evaluation results are needed in the frontend long before LLVM IR ever comes into the picture.

Also, people have done interesting things in constexpr that currently suffer from slow compile times: https://github.com/hanickadot/compile-time-regular-expressio...

I may not know modern C++ well enough, but I would think that, if you go through a translation unit, discarding everything ”not constexpr”, the result should compile to an object file without any code.

Repeat compilation (conceptually, the implementation might be more efficient), replacing anything ”constexpr” by what you got earlier, and you’re done.

Or am I overlooking something?

constexpr functions aren't restricted to compile time, they can also be used at runtime. Thus constexpr functions can show up in the final executable. Constexpr functions can also control what gets compiled in the first place. For example you can use the result of a constexpr evaluation to instantiate a template.

This is hilarious. Yes, it turns out making constexpr into a general-purpose C++ emulator in the compiler is really fricking slow.

Maybe native code-generation isn't so bad, after all. Maybe we can just redefine "constexpr" to nothing, then compilers can just dump it all in a file, compile it, run it and there we go, the blazing fast integrated code generation pipeline we all seem to want and need.

> Maybe we can just redefine "constexpr" to nothing, then compilers can just dump it all in a file, compile it, run it and there we go, the blazing fast integrated code generation pipeline we all seem to want and need.

The semantics of constexpr do not allow for undefined behavior, so this would unfortunately not be feasible.

> is really fricking slow

But the problem is, as far as I can see, that the whole "Interpreter" project is started based on the assumptions, not on the realistic measurement of real life timings for real life inputs.

At least in the text no proof is presented that the work is really justifiable.

And so it begins. This could mark the begin of C++, the dynamic language. I like that.

Reply on news.ycombinator.com