Re: [boost] constexpr, cmath functions and other functions and distributions

Subject: Re: [boost] constexpr, cmath functions and other functions and distributions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-07-28 11:07:54

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.