C++ constexpr "library"? (not pre-compiled header)

[jlmxyz]

Hi
C++ constexpr is really a killer feature, allowing to create small byte code at compile time for everything that is deterministic, while allowing the same code to be used on what isn't deterministic.
In a way it's better than a template.

as template, and inline, they have the issue to be "recompiled" in each module they are used, this can increase the compile time and also make it difficult to share it in a library.
The compiler can also choose not to inline the function.

pre-compiled header don't match my needs

so I wonder if there is some compile option flag that could allow me to create a library (shared and static) providing my constexpr functions (aside my non constexpr functions) and pass it as an argument when compiling my modules

1. the constexpr function in library is assumed to be uptodate with the source in header (this is the role of the make system) once the library arg is provided.
2. if the function is used in module, and constexpr can be evaluated at compile time, then the compiler call the library function and use the result
3. if the function is used in module, and constexpr can't be evaluated at compile time
   1. if the function is inline-able : the library code is copied in place, maybe modified to remove the function call overhead (argument creation and return value removal), don't know if there is a way in library to create functions that can't be called, but just stored, so without the overhead, in which case, the library act like a compiler cache, but not sure if it's something that is interesting or if the function should be usable and "dlopen-usable"
   2. if the function is not inline-able : the symbol resolution is performed at link time as a regular library function

this will save lot of time in compilation, while taking full advantage of constexpr code optimization (size and speed)

thanks and regards

[llvmbot]

@llvm/issue-subscribers-c-1

Author: None (jlmxyz)

Hi C++ constexpr is really a killer feature, allowing to create small byte code at compile time for everything that is deterministic, while allowing the same code to be used on what isn't deterministic. In a way it's better than a template.

as template, and inline, they have the issue to be "recompiled" in each module they are used, this can increase the compile time and also make it difficult to share it in a library.
The compiler can also choose not to inline the function.

pre-compiled header don't match my needs

so I wonder if there is some compile option flag that could allow me to create a library (shared and static) providing my constexpr functions (aside my non constexpr functions) and pass it as an argument when compiling my modules

1. the constexpr function in library is assumed to be uptodate with the source in header (this is the role of the make system) once the library arg is provided.
2. if the function is used in module, and constexpr can be evaluated at compile time, then the compiler call the library function and use the result
3. if the function is used in module, and constexpr can't be evaluated at compile time
   1. if the function is inline-able : the library code is copied in place, maybe modified to remove the function call overhead (argument creation and return value removal), don't know if there is a way in library to create functions that can't be called, but just stored, so without the overhead, in which case, the library act like a compiler cache, but not sure if it's something that is interesting or if the function should be usable and "dlopen-usable"
   2. if the function is not inline-able : the symbol resolution is performed at link time as a regular library function

this will save lot of time in compilation, while taking full advantage of constexpr code optimization (size and speed)

thanks and regards

[efriedma-quic]

constexpr evaluation isn't directly equivalent to runtime evaluation. We need a different representation to allow the compiler to evaluate everything it's allowed to evaluate using the target's representation, and generate diagnostics for things it isn't allowed to evaluate. So anything that runs at runtime is a completely different codepath from constexpr evaluation at compile-time.

It is possible to compile a constexpr function into a sort of bytecode. Actually, we already have code to do that, in clang/lib/AST/ByteCode/ . It's not on by default yet, but it can be enabled with -fexperimental-new-constant-interpreter. (If you're interested, we're looking for new contributors in the area.)

We currently don't serialize the bytecode, but we could, in theory. Not sure how practically useful that would be. You can already serialize the AST using C++ modules, and converting the AST to bytecode isn't that expensive.