6 ms·
ConstExprPreter – Clang Constexpr Interpreter
- bla3 7y agoThe 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.
- stefan_ 7y agoThis 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 7y ago> 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.
- acqq 7y ago> 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.
- gumby 7y agoI 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 7y agoThat 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 7y agoI 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".
- bigcheesegs 7y agoYeah, on variable decls it does indeed mean const. It also means inline on functions and static data members (but not global variables).
- gumby 7y ago
- Someone 7y agoDoes 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.
- legulere 7y agoYou cannot use memcpy in constant expressions so you have to iterate by hand for copying.
- bigcheesegs 7y agoconstexpr 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-expressions https://github.com/hanickadot/compile-time-regular-expressio...
- deleted 7y ago[deleted]
- Someone 7y agoI 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 7y agoconstexpr 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.
- deleted 7y ago[deleted]
- rurban 7y agoAnd so it begins. This could mark the begin of C++, the dynamic language. I like that.