
ConstExprPreter – Clang Constexpr Interpreter - gbrown_
https://lists.llvm.org/pipermail/cfe-dev/2019-July/062799.html
======
bla3
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.

~~~
zamalek
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)?

~~~
comex
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.

------
gumby
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/

~~~
bigcheesegs
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.

~~~
haberman
I thought constexpr implies const:
[https://godbolt.org/z/u3a1pq](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".

~~~
gumby
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.

~~~
bigcheesegs
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.

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

~~~
bigcheesegs
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...](https://github.com/hanickadot/compile-time-regular-expressions)

~~~
Someone
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?

~~~
bigcheesegs
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.

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

~~~
saagarjha
> 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.

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

