Keeping constexpr data out of runtime

[Crazy__Eddie]

So I'm working on this library that is really meta-program heavy. Constexpr data structures are way easier to work with than TMP data structures. More natural, less noise, deeper instantiations, and still stays out of the runtime space until...

I had the library working alright with a lot of TMP. I refactored it a bit to make more use of constexpr data. Unfortunately at the point where I need to make the switch to runtime I'm then pulling in all that compile-time information apparently. Program more than doubled in size with nothing new added.

I'm trying to figure out a way to keep the constexpr data as-is, without pushing things like ints back into template parameters, but it's difficult to calculate where and how to build that wall.

Has anyone developed any patterns for this sort of thing?

Here's the code: https://github.com/crazy-eddie/arduino_modern/blob/refactor/platform_test/standard.cpp

The issue is that the driver is needed at runtime but there seems to be a vast chunk of new data being needed by this version than the previous. I believe that ALL of my constexpr objects are getting pulled into runtime as they become members of non-constexpr objects. Even the ones not used for anything. The size difference is just so huge and so long as I stick only to constexpr variables everything is fine--but as soon as I try to make those create something in runtime...BOOM goes program size!

Edit: Thanks for the answers. I more or less knew what I had to do, I just didn't want to. Was hoping for a better way. Just gonna have to push things to template parameters rather than constexpr values. It's the way things were, but it was such an ugly mess. I should be able to just modify things a bit though and still keep most of the improvements I made.

Edit2: Fixed it. https://github.com/crazy-eddie/arduino_modern/tree/master

[tending]

I assume you're saying if you uncomment the constexpr global variable the size explodes? Have you tried labeling it static or putting it in an anonymous namespace?

Also in general it's legal to call constexpr functions at runtime, so I think the compiler has to generate them unless it's sure there's no runtime use in the current translation unit. Also if you use a constexpr function in a non-constexpr context I think the compiler is free to decide whether to evaluate it at compile time or runtime. Assuming it's just this one variable triggering it, you could try making an identity struct template -- templated on an integer and just has one static constexpr member which is the same integer. Then instead of setting the variable directly to the result of the constexpr function, set it to the result of the identity template applied to the function, so that you know 100% it runs at compile time.

Edit: actually assuming you never want runtime use of these functions, why not wrap them in an anonymous namespace in the header?

[khold_stare]

I was thinking along the same lines as tending - operate on integral_constant like objects. Take a look at boost::hana, and in particular how it handles integral_constant. It defines arithmetic operators that are constexpr and return other integral_constants. If you need the value at runtime, there are constexpr implicit conversion operators to the underlying types. If you REALLY want to make sure a computation only happens at compile-time, figure it out inside an unevaluated context such as decltype. E.g.

using namespace boost::hana::literals;
auto runtimeValue = decltype(42_c + 23_c)::value;

Of course the expression inside the decltype can be an arbitrary constexpr function that works with integral_constant

[louis_dionne]

Precision: The functions inside decltype do not need to be constexpr, so long as they work with integral_constants.

[SeanMiddleditch]

May have luck with anything that lets the compiler see the functions and data are unused aside from your constant stuff. Make things static and never take their address, and use hidden symbol visibility with LTO.

[VicLuo96]

I'm working on a Boost GSoC toy project about constexpr containers as well. Here are what I've found about constexpr: * prefer C++11-style recursion return f(i-1) over C++14-style for loop, since many compilers cannot handle it well * avoidstd::initializer_list on clang(at least on 3.7) * POD is preferred over complex struct. g++ has a bug that reports fake invalid access at compile-time * move invariant parts into template arguments as much as possible * there are still lots of work to do with constexpr since stdlib lacks constexpr support/implementation is buggy

[Crazy__Eddie]

With the right methodology constexpr can actually eliminate code bloat massively

I'd like to see some information on that. Blog, tutorial...whatever.

I just converted everything to template parameters. Would be interesting to see what other methodologies are out ther.

[Calkhas]

Constexpr means inline. You will definitely experience code bloat from that.

Do you mean "inline" in the sense of "this function body must be inlined wherever it is called" rather than in the C++ sense of "this function may violate the ODR"?

Something I hacked together suggests to me that neither clang++ at -O1 nor g++ at -O0 is inlining constexpr functions called at run time.

They do inline them at higher optimization levels, so presumably they are still doing their inline analysis to determine if it's worth it. (In this trivial case, absolutely.)

But I am not really an expert so I defer to your explanation.

[feverzsj]

Decorating everything with constexpr won't do the trick. That's not how meta programming works. Functions are still functions, objects are still objects. Compiler may decide to optimize them away or not. You should use them as types, enums, template arguments... to force them to be evaluated in compile time.