Using U_mm inside a compilation unit will force the compiler to generate
a runtime copy of the function, and we don't want that.
But there seems also to be an optimization problem with gcc <= 7.x where
even when declaring an inline function constexpr, if called enough
times, the compiler will choose not to evaluate the function at
compile time and thus avoid our compile-time float->integer
conversions...
For this reason, split the body of the function in two parts: the actual
function that uses AxisUnits at runtime for calling motion.PlanMove, and
a wrapper that forces the conversion. By marking this function as
always_inline, the body is correctly evaluated at compile time at each
call site.
Nasty. Actually, that sounds exactly the sort of behavior "consteval" attempts to solve, but that's... c++20 .. always too late ;)
I checked the assembly output only on gcc 7.x with #183
Using U_mm inside a compilation unit will force the compiler to generate a runtime copy of the function, and we don't want that.
But there seems also to be an optimization problem with gcc <= 7.x where even when declaring an inline function constexpr, if called enough times, the compiler will choose not to evaluate the function at compile time and thus avoid our compile-time float->integer conversions...
For this reason, split the body of the function in two parts: the actual function that uses AxisUnits at runtime for calling motion.PlanMove, and a wrapper that forces the conversion. By marking this function as always_inline, the body is correctly evaluated at compile time at each call site.
Nasty. Actually, that sounds exactly the sort of behavior "consteval" attempts to solve, but that's... c++20 .. always too late ;)
I checked the assembly output only on gcc 7.x with #183