On 07/28/16 16:24, Paul A. Bristow wrote:
After much head scratching (and some head banging) - against a string of "Computer Says No" inscrutable diagnostic messages.
I believe that I have now produced a (partial) version of Boost.Math normal_distribution that can be a constexpr using GCC6.1.1.
(diagnosis has got to improve if constexprizing existing code is to become popular? )
constexpr normal_distribution<double> n01(0., 1.);
producing this code
960 .loc 1 47 0
961 000d 660FEFC0 pxor %xmm0, %xmm0 # tmp89
962 0011 F20F1145 movsd %xmm0, -32(%rbp) # tmp89, n01.m_mean
962 E0
963 0016 F20F1005 movsd .LC1(%rip), %xmm0 #, tmp90
963 80080000
964 001e F20F1145 movsd %xmm0, -24(%rbp) # tmp90, n01.m_sd
964 E8
and more interestingly, a PDF can be calculated at compile-time
constexpr double p = pdf(n01, 0.5);
965 .loc 1 56 0
966 0023 F20F1005 movsd .LC2(%rip), %xmm0 #, tmp91
966 88080000
967 002b F20F1145 movsd %xmm0, -8(%rbp) # tmp91, p
967 F8
Perhaps the assembler whizzes can confirm that this looks like a compile-time computation?
The instrunctions just transfer double values from one location to another, so if the constants are results of some computation then yes, the computation took place at compile time. However, I'm not so sure that constexpr took part in that optimization. First, I think FP math has always been out of the compile time (as far as the language is concerned). For instance, you can't put a FP operation in a static_assert. Has this changed in the latest standards? Second, gcc is known to be able to perform FP computations on constants in compile time. This is not related to constexpr but rather is an optimization. The computation simply has to be visible to the compiler (e.g. with help of the old-fashion inline functions). Other compilers may be similarly capable, but AFAIK are not required to.