------=_Part_204_429265247.1486646366897
Content-Type: multipart/alternative;
 boundary="----=_Part_205_2061782630.1486646366897"

------=_Part_205_2061782630.1486646366897
Content-Type: text/plain; charset=UTF-8

AFAIK none of the major C++ compilers provide a way to detect whether a
constexpr function is being evaluated at compile-time.

This is unfortunate. I have a constexpr function with bad run-time
performance. Rewriting it to use SSE4.2 intrinsics improves its performance
by 3.5x. Those intrinsics are not constexpr functions. I could imagine
similar situations in which one would need to go down to inline assembly to
deliver acceptable run-time performance in constexpr functions. Inline
assembly cannot be neither standardized nor evaluated at compile-time.

So I must choose: either constexpr (which my function already was) but
horrible run-time performance, or run-time performance and breakage
(because my function was already constexpr). This is an uncomfortable spot
to be in. In particular, since constexpr functions are not limited to
compile-time evaluation.

There are some unreliable hacks to workaround this. For example using GCC,
if all arguments of a function are "__builtin_constant_p(arg) == true",
chances are that the function is being evaluated at compile-time.
Obviously, this hack is neither reliable nor portable.

Some people have particularly argued for "constexpr overloading" and other
complicated features in the past [0, 1]. The main argument against those
was that the committee preferred to improve constexpr so that faster
run-time algorithms can be implemented without hacks, than offering a
escape hatch. I don't see how this could ever work for somebody wanting to
use inline assembly for the run-time implementation of a constexpr
function, and hence argue that we do need a escape hatch.

I think that a standard library function, "constexpr bool
std::is_context_being_constant_evaluated();", would be a simple addition to
the language that solves all the needs to differentiate between run-time
and compile-time code in constexpr functions. It does not have any of the
complications of a new constexpr overloading mechanism.

There is also prior art in the D language, where the __ctfe intrinsic is
provided [3], and quoting its documentation, defined as:
> The __ctfe boolean pseudo-variable, which evaluates to true at compile
time, but false at run time, can be used to provide an alternative
execution path to avoid operations which are forbidden at compile time.
Every usage of __ctfe is evaluated before code generation and therefore has
no run-time cost, even if no optimizer is used.

[0] https://drive.google.com/file/d/0B0-xyi_NILkZeUxCWjdudW52UjQ/view
[1] https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/constexpr$20overloading/std-proposals/1MxiNSeJAj8/s4BXtHnA_pwJ
[3] http://dlang.org/spec/function.html

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86a47916-27c3-4e29-862f-9b4e1f105c1c%40isocpp.org.

------=_Part_205_2061782630.1486646366897
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">AFAIK none of the major C++ compilers provide a way to det=
ect whether a constexpr function is being evaluated at compile-time.<br><br=
>This is unfortunate. I have a constexpr function with bad run-time perform=
ance. Rewriting it to use SSE4.2 intrinsics improves its performance by 3.5=
x. Those intrinsics are not constexpr functions. I could imagine similar si=
tuations in which one would need to go down to inline assembly to deliver a=
cceptable run-time performance in constexpr functions. Inline assembly cann=
ot be neither standardized nor evaluated at compile-time.=C2=A0<br><br>So I=
 must choose: either constexpr (which my function already was) but horrible=
 run-time performance, or run-time performance and breakage (because my fun=
ction was already constexpr). This is an uncomfortable spot to be in. In pa=
rticular, since constexpr functions are not limited to compile-time evaluat=
ion.<br><br>There are some unreliable hacks to workaround this. For example=
 using GCC, if all arguments of a function are &quot;__builtin_constant_p(a=
rg) =3D=3D true&quot;, chances are that the function is being evaluated at =
compile-time. Obviously, this hack is neither reliable nor portable.=C2=A0<=
br><br>Some people have particularly argued for &quot;constexpr overloading=
&quot; and other complicated features in the past [0, 1]. The main argument=
 against those was that the committee preferred to improve constexpr so tha=
t faster run-time algorithms can be implemented without hacks, than offerin=
g a escape hatch. I don&#39;t see how this could ever work for somebody wan=
ting to use inline assembly for the run-time implementation of a constexpr =
function, and hence argue that we do need a escape hatch.<br><br>I think th=
at a standard library function, &quot;constexpr bool std::is_context_being_=
constant_evaluated();&quot;, would be a simple addition to the language tha=
t solves all the needs to differentiate between run-time and compile-time c=
ode in constexpr functions. It does not have any of the complications of a =
new constexpr overloading mechanism.=C2=A0<div><br></div><div>There is also=
 prior art in the D language, where the __ctfe intrinsic is provided [3], a=
nd quoting its documentation, defined as:<br>&gt; The __ctfe boolean pseudo=
-variable, which evaluates to true at compile time, but false at run time, =
can be used to provide an alternative execution path to avoid operations wh=
ich are forbidden at compile time. Every usage of __ctfe is evaluated befor=
e code generation and therefore has no run-time cost, even if no optimizer =
is used.<br><br></div><div><div><div>[0]=C2=A0https://drive.google.com/file=
/d/0B0-xyi_NILkZeUxCWjdudW52UjQ/view</div><div>[1]=C2=A0https://groups.goog=
le.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/constexpr$20o=
verloading/std-proposals/1MxiNSeJAj8/s4BXtHnA_pwJ</div></div></div><div>[3]=
=C2=A0http://dlang.org/spec/function.html</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/86a47916-27c3-4e29-862f-9b4e1f105c1c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/86a47916-27c3-4e29-862f-9b4e1f105c1c=
%40isocpp.org</a>.<br />

------=_Part_205_2061782630.1486646366897--

------=_Part_204_429265247.1486646366897--

.

------=_Part_205_1427550062.1486647215406
Content-Type: multipart/alternative;
 boundary="----=_Part_206_2053102133.1486647215406"

------=_Part_206_2053102133.1486647215406
Content-Type: text/plain; charset=UTF-8

In [0] Chandler Carruth discusses a different approach using attributes
that is nicer:

// constexpr implementation
constexpr int foo_constexpr_impl();

// run-time implementation with fallback
// to the constexpr implementation in
// constant-evaluated contexts
[[constexpr_alias(foo_constexpr_impl)]]
int foo();

I wonder what happened to this proposal. Gabriel Dos Reis argues there that
we should focus on making constexpr better, but Richard Smith argued:

Yes, I completely agree, but I don't think this solves the whole
> problem {{referring to improving constexpr}}. There are certain constructs
> which we are unlikely to *ever*
> permit in constexpr functions, such as (as an extreme case) inline
> assembly. Where possible, we should share an implementation between
> compile time and runtime. This proposal is for the exceptional cases
> (which, over time, should become fewer and fewer), and as a stopgap
> measure while we work towards the right solution.


[0]
http://clang-developers.42468.n3.nabble.com/C-11-new-builtin-to-allow-constexpr-to-be-applied-to-performance-critical-functions-td4027593.html
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/274e92cb-25e3-4e32-b13e-6d419cd8c5e3%40isocpp.org.

------=_Part_206_2053102133.1486647215406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In [0] Chandler Carruth discusses a different approach usi=
ng attributes that is nicer:<br><br>// constexpr implementation<br>constexp=
r int foo_constexpr_impl();<br><br>// run-time implementation with fallback=
<div>// to the constexpr implementation in=C2=A0</div><div>// constant-eval=
uated contexts<br>[[constexpr_alias(foo_constexpr_impl)]]<br>int foo();<br>=
<br>I wonder what happened to this proposal. Gabriel Dos Reis argues there =
that we should focus on making constexpr better, but Richard Smith argued:<=
br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Yes, I com=
pletely agree, but I don&#39;t think this solves the whole=C2=A0<br>problem=
 {{referring to improving constexpr}}. There are certain constructs which w=
e are unlikely to *ever*<br> permit in constexpr functions, such as (as an =
extreme case) inline<br> assembly. Where possible, we should share an imple=
mentation between<br> compile time and runtime. This proposal is for the ex=
ceptional cases<br> (which, over time, should become fewer and fewer), and =
as a stopgap<br> measure while we work towards the right solution. </blockq=
uote><br>[0] http://clang-developers.42468.n3.nabble.com/C-11-new-builtin-t=
o-allow-constexpr-to-be-applied-to-performance-critical-functions-td4027593=
..html<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"></div></=
blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/274e92cb-25e3-4e32-b13e-6d419cd8c5e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/274e92cb-25e3-4e32-b13e-6d419cd8c5e3=
%40isocpp.org</a>.<br />

------=_Part_206_2053102133.1486647215406--

------=_Part_205_1427550062.1486647215406--

.

--001a114f50da5e88f60548195a13
Content-Type: text/plain; charset=UTF-8

On 9 February 2017 at 13:33, Gonzalo BG <gonzalobg88@gmail.com> wrote:

> In [0] Chandler Carruth discusses a different approach using attributes
> that is nicer:
>
> // constexpr implementation
> constexpr int foo_constexpr_impl();
>
> // run-time implementation with fallback
> // to the constexpr implementation in
> // constant-evaluated contexts
> [[constexpr_alias(foo_constexpr_impl)]]
> int foo();
>
> I wonder what happened to this proposal. Gabriel Dos Reis argues there
> that we should focus on making constexpr better, but Richard Smith argued:
>
> Yes, I completely agree, but I don't think this solves the whole
>> problem {{referring to improving constexpr}}. There are certain
>> constructs which we are unlikely to *ever*
>> permit in constexpr functions, such as (as an extreme case) inline
>> assembly. Where possible, we should share an implementation between
>> compile time and runtime. This proposal is for the exceptional cases
>> (which, over time, should become fewer and fewer), and as a stopgap
>> measure while we work towards the right solution.
>
>
> [0] http://clang-developers.42468.n3.nabble.com/C-11-new-builtin
> -to-allow-constexpr-to-be-applied-to-performance-critica
> l-functions-td4027593.html
>

I'd personally prefer to add constexpr as a qualifier on the parameters and
overload based on that, that would be much more generic.
Good luck extending C++ to make that work though.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_zgzJKgyp7%3D%2Bmds3uNsDLVvv5ZsL3uCd_R_e%3DBQAvQQQ%40mail.gmail.com.

--001a114f50da5e88f60548195a13
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 9=
 February 2017 at 13:33, Gonzalo BG <span dir=3D"ltr">&lt;<a href=3D"mailto=
:gonzalobg88@gmail.com" target=3D"_blank">gonzalobg88@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In [0] Chandl=
er Carruth discusses a different approach using attributes that is nicer:<b=
r><br>// constexpr implementation<br>constexpr int foo_constexpr_impl();<br=
><br>// run-time implementation with fallback<div>// to the constexpr imple=
mentation in=C2=A0</div><div>// constant-evaluated contexts<br>[[constexpr_=
alias(foo_constexp<wbr>r_impl)]]<br>int foo();<br><br>I wonder what happene=
d to this proposal. Gabriel Dos Reis argues there that we should focus on m=
aking constexpr better, but Richard Smith argued:<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Yes, I completely agree, but I don&#39;t t=
hink this solves the whole=C2=A0<br>problem {{referring to improving conste=
xpr}}. There are certain constructs which we are unlikely to *ever*<br> per=
mit in constexpr functions, such as (as an extreme case) inline<br> assembl=
y. Where possible, we should share an implementation between<br> compile ti=
me and runtime. This proposal is for the exceptional cases<br> (which, over=
 time, should become fewer and fewer), and as a stopgap<br> measure while w=
e work towards the right solution. </blockquote><br>[0] <a href=3D"http://c=
lang-developers.42468.n3.nabble.com/C-11-new-builtin-to-allow-constexpr-to-=
be-applied-to-performance-critical-functions-td4027593.html" target=3D"_bla=
nk">http://clang-developers.42468.<wbr>n3.nabble.com/C-11-new-builtin<wbr>-=
to-allow-constexpr-to-be-<wbr>applied-to-performance-critica<wbr>l-function=
s-td4027593.html</a></div></div></blockquote><div><br></div><div>I&#39;d pe=
rsonally prefer to add constexpr as a qualifier on the parameters and overl=
oad based on that, that would be much more generic.</div><div>Good luck ext=
ending C++ to make that work though.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya_zgzJKgyp7%3D%2Bmds3uNsDLVvv5Z=
sL3uCd_R_e%3DBQAvQQQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya_zgz=
JKgyp7%3D%2Bmds3uNsDLVvv5ZsL3uCd_R_e%3DBQAvQQQ%40mail.gmail.com</a>.<br />

--001a114f50da5e88f60548195a13--

.

------=_Part_245_143470699.1486650027769
Content-Type: multipart/alternative;
 boundary="----=_Part_246_887074268.1486650027770"

------=_Part_246_887074268.1486650027770
Content-Type: text/plain; charset=UTF-8

> I'd personally prefer to add constexpr as a qualifier on the parameters
and overload based on that, that would be much more generic.

Are constexpr functions required to be evaluated at compile-time if all
parameters are constant expressions? I thought that they are only required
to be evaluated at compile-time in constant expression contexts and
potentially also in unevaluated contexts.

Anyhow your preference is appealing, and could be a backwards compatible
(and very complex) addition to either of the things being proposed.

However, note that while it might make some programs easier to write, it
does not allow writing new programs, since it can be worked around with if
constexpr +  `std::is_const_evaluated(arg)`.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/33a0dd40-e762-4f98-9ecc-c48ca4a8a74b%40isocpp.org.

------=_Part_246_887074268.1486650027770
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; I&#39;d personally prefer to add constexpr as a quali=
fier on the parameters and overload based on that, that would be much more =
generic.<br><div><br>Are constexpr functions required to be evaluated at co=
mpile-time if all parameters are constant expressions? I thought that they =
are only required to be evaluated at compile-time in constant expression co=
ntexts and potentially also in unevaluated contexts.=C2=A0<br><br>Anyhow yo=
ur preference is appealing, and could be a backwards compatible (and very c=
omplex) addition to either of the things being proposed. <br><br>However, n=
ote that while it might make some programs easier to write, it does not all=
ow writing new programs, since it can be worked around with if constexpr + =
=C2=A0`std::is_const_evaluated(arg)`.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/33a0dd40-e762-4f98-9ecc-c48ca4a8a74b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33a0dd40-e762-4f98-9ecc-c48ca4a8a74b=
%40isocpp.org</a>.<br />

------=_Part_246_887074268.1486650027770--

------=_Part_245_143470699.1486650027769--

.

------=_Part_251_216376776.1486653682496
Content-Type: multipart/alternative;
 boundary="----=_Part_252_1409025950.1486653682496"

------=_Part_252_1409025950.1486653682496
Content-Type: text/plain; charset=UTF-8



On Thursday, February 9, 2017 at 8:19:27 AM UTC-5, Gonzalo BG wrote:
>
> AFAIK none of the major C++ compilers provide a way to detect whether a
> constexpr function is being evaluated at compile-time.
>
> This is unfortunate. I have a constexpr function with bad run-time
> performance. Rewriting it to use SSE4.2 intrinsics improves its performance
> by 3.5x. Those intrinsics are not constexpr functions. I could imagine
> similar situations in which one would need to go down to inline assembly to
> deliver acceptable run-time performance in constexpr functions. Inline
> assembly cannot be neither standardized nor evaluated at compile-time.
>
> So I must choose: either constexpr (which my function already was) but
> horrible run-time performance, or run-time performance and breakage
> (because my function was already constexpr). This is an uncomfortable spot
> to be in. In particular, since constexpr functions are not limited to
> compile-time evaluation.
>
> There are some unreliable hacks to workaround this. For example using GCC,
> if all arguments of a function are "__builtin_constant_p(arg) == true",
> chances are that the function is being evaluated at compile-time.
> Obviously, this hack is neither reliable nor portable.
>
> Some people have particularly argued for "constexpr overloading" and other
> complicated features in the past [0, 1]. The main argument against those
> was that the committee preferred to improve constexpr so that faster
> run-time algorithms can be implemented without hacks, than offering a
> escape hatch. I don't see how this could ever work for somebody wanting to
> use inline assembly for the run-time implementation of a constexpr
> function, and hence argue that we do need a escape hatch.
>
> I think that a standard library function, "constexpr bool
> std::is_context_being_constant_evaluated();", would be a simple addition to
> the language that solves all the needs to differentiate between run-time
> and compile-time code in constexpr functions. It does not have any of the
> complications of a new constexpr overloading mechanism.
>

I think there's a much easier way: `if constexpr`.

As it currently stands, `if constexpr()` is a compile error, since there is
no expression to evaluate. What if we make it so that `if constexpr()`
means "if I'm in a constant expression evaluation". And thus, the `else`
clause would be "if I'm not in a constant expression evaluation".

After all, 90% of the time you're going to call
`is_context_being_constant_evaluated`, you're going to use it in an `if
constexpr` statement. So let's just skip the middleman.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f8a6ac63-391f-4b21-b4e2-e70f333b554d%40isocpp.org.

------=_Part_252_1409025950.1486653682496
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, February 9, 2017 at 8:19:27 AM UTC-5,=
 Gonzalo BG wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">AFAIK none of the major C++ compilers provide a way to detect whether =
a constexpr function is being evaluated at compile-time.<br><br>This is unf=
ortunate. I have a constexpr function with bad run-time performance. Rewrit=
ing it to use SSE4.2 intrinsics improves its performance by 3.5x. Those int=
rinsics are not constexpr functions. I could imagine similar situations in =
which one would need to go down to inline assembly to deliver acceptable ru=
n-time performance in constexpr functions. Inline assembly cannot be neithe=
r standardized nor evaluated at compile-time.=C2=A0<br><br>So I must choose=
: either constexpr (which my function already was) but horrible run-time pe=
rformance, or run-time performance and breakage (because my function was al=
ready constexpr). This is an uncomfortable spot to be in. In particular, si=
nce constexpr functions are not limited to compile-time evaluation.<br><br>=
There are some unreliable hacks to workaround this. For example using GCC, =
if all arguments of a function are &quot;__builtin_constant_p(arg) =3D=3D t=
rue&quot;, chances are that the function is being evaluated at compile-time=
.. Obviously, this hack is neither reliable nor portable.=C2=A0<br><br>Some =
people have particularly argued for &quot;constexpr overloading&quot; and o=
ther complicated features in the past [0, 1]. The main argument against tho=
se was that the committee preferred to improve constexpr so that faster run=
-time algorithms can be implemented without hacks, than offering a escape h=
atch. I don&#39;t see how this could ever work for somebody wanting to use =
inline assembly for the run-time implementation of a constexpr function, an=
d hence argue that we do need a escape hatch.<br><br>I think that a standar=
d library function, &quot;constexpr bool std::is_context_being_<wbr>constan=
t_evaluated();&quot;, would be a simple addition to the language that solve=
s all the needs to differentiate between run-time and compile-time code in =
constexpr functions. It does not have any of the complications of a new con=
stexpr overloading mechanism.</div></blockquote><div><br>I think there&#39;=
s a much easier way: `if constexpr`.<br><br>As it currently stands, `if con=
stexpr()` is a compile error, since there is no expression to evaluate. Wha=
t if we make it so that `if constexpr()` means &quot;if I&#39;m in a consta=
nt expression evaluation&quot;. And thus, the `else` clause would be &quot;=
if I&#39;m not in a constant expression evaluation&quot;.<br><br>After all,=
 90% of the time you&#39;re going to call `is_context_being_constant_evalua=
ted`, you&#39;re going to use it in an `if constexpr` statement. So let&#39=
;s just skip the middleman.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f8a6ac63-391f-4b21-b4e2-e70f333b554d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f8a6ac63-391f-4b21-b4e2-e70f333b554d=
%40isocpp.org</a>.<br />

------=_Part_252_1409025950.1486653682496--

------=_Part_251_216376776.1486653682496--

.

IMHO, if you have a valid use case that improves the performance of
your code (and resonates with "enough" domain experts) - yet is very
challenging (if not impossible) to implement in current C++, we should
at the very least strongly consider providing it as an extension in
clang (which I believe should not be hard to implement - i.e. codegen
ignores the true-branch, and Richard's expression evaluator ignores
the false-branch).

Whether the standardization committee will ever embrace it (following
a paper), is quite another matter (and might depend on the quality and
reputation of the code-bases that emerge around it) ...

Faisal Vali



On Thu, Feb 9, 2017 at 7:19 AM, Gonzalo BG <gonzalobg88@gmail.com> wrote:
> AFAIK none of the major C++ compilers provide a way to detect whether a
> constexpr function is being evaluated at compile-time.
>
> This is unfortunate. I have a constexpr function with bad run-time
> performance. Rewriting it to use SSE4.2 intrinsics improves its performance
> by 3.5x. Those intrinsics are not constexpr functions. I could imagine
> similar situations in which one would need to go down to inline assembly to
> deliver acceptable run-time performance in constexpr functions. Inline
> assembly cannot be neither standardized nor evaluated at compile-time.
>
> So I must choose: either constexpr (which my function already was) but
> horrible run-time performance, or run-time performance and breakage (because
> my function was already constexpr). This is an uncomfortable spot to be in.
> In particular, since constexpr functions are not limited to compile-time
> evaluation.
>
> There are some unreliable hacks to workaround this. For example using GCC,
> if all arguments of a function are "__builtin_constant_p(arg) == true",
> chances are that the function is being evaluated at compile-time. Obviously,
> this hack is neither reliable nor portable.
>
> Some people have particularly argued for "constexpr overloading" and other
> complicated features in the past [0, 1]. The main argument against those was
> that the committee preferred to improve constexpr so that faster run-time
> algorithms can be implemented without hacks, than offering a escape hatch. I
> don't see how this could ever work for somebody wanting to use inline
> assembly for the run-time implementation of a constexpr function, and hence
> argue that we do need a escape hatch.
>
> I think that a standard library function, "constexpr bool
> std::is_context_being_constant_evaluated();", would be a simple addition to
> the language that solves all the needs to differentiate between run-time and
> compile-time code in constexpr functions. It does not have any of the
> complications of a new constexpr overloading mechanism.
>
> There is also prior art in the D language, where the __ctfe intrinsic is
> provided [3], and quoting its documentation, defined as:
>> The __ctfe boolean pseudo-variable, which evaluates to true at compile
>> time, but false at run time, can be used to provide an alternative execution
>> path to avoid operations which are forbidden at compile time. Every usage of
>> __ctfe is evaluated before code generation and therefore has no run-time
>> cost, even if no optimizer is used.
>
> [0] https://drive.google.com/file/d/0B0-xyi_NILkZeUxCWjdudW52UjQ/view
> [1]
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/constexpr$20overloading/std-proposals/1MxiNSeJAj8/s4BXtHnA_pwJ
> [3] http://dlang.org/spec/function.html
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/86a47916-27c3-4e29-862f-9b4e1f105c1c%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABsSTho9bW015Eo7KNEBoYs2snREYJYzn6SdQGjYMy64zZETnA%40mail.gmail.com.

.

On quinta-feira, 9 de fevereiro de 2017 09:24:09 PST Faisal Vali wrote:
> IMHO, if you have a valid use case that improves the performance of
> your code (and resonates with "enough" domain experts) - yet is very
> challenging (if not impossible) to implement in current C++, we should
> at the very least strongly consider providing it as an extension in
> clang (which I believe should not be hard to implement - i.e. codegen
> ignores the true-branch, and Richard's expression evaluator ignores
> the false-branch).

He's not the first to bring it up. I believe I have more than once prior to
this and the examples are all the same: trying to do something that isn't
constexpr but is faster at runtime. In 90% of the cases, it's either due to
inline assembly or compiler intrinsics that aren't constexpr. I have yet to
see clever, non-constexpr hacky code that doesn't involve either, but it's
possible.

We used to have this problem with Clang: for example, qCountTrailingZeroBits
wasn't constexpr with Clang until 3.8, because we couldn't use __builtin_ctz
in a constexpr context.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12459132.29Ej4iibtf%40tjmaciei-mobl1.

.

On quinta-feira, 9 de fevereiro de 2017 10:12:30 PST Thiago Macieira wrote:
> He's not the first to bring it up. I believe I have more than once prior to
> this and the examples are all the same: trying to do something that isn't
> constexpr but is faster at runtime. In 90% of the cases, it's either due to
> inline assembly or compiler intrinsics that aren't constexpr. I have yet to
> see clever, non-constexpr hacky code that doesn't involve either, but it's
> possible.

Here's an idea: anything related to type punning via memcpy.

Given enough __builtin constexpr floating point functions, you can implement
conversion to __fp16 (a.k.a. ushort) in constexpr fashion. But if you know
that you're under IEEE 754 / IEC 559, you could simply memcpy the float to
uint32_t (or double to uint64_t) and extract the bits that you need.

    uint64_t v;
    memcpy(&v, &val, sizeof(v));
    int sign = v >> 63 << 15;
    int exp = (v >> 52) & 0x7ff;
    int mant = v << 12 >> 12 >> (53-11);    /* keep only the 11 most
significant bits of the mantissa */
    exp -= 1023;
    if (exp == 1024) {
        /* infinity or NaN */
        exp = 16;
        mant >>= 1;
    } else if (exp >= 16) {
        /* overflow, as largest number */
        exp = 15;
        mant = 1023;
    } else if (exp >= -14) {
        /* regular normal */
    } else if (exp >= -24) {
        /* subnormal */
        mant |= 1024;
        mant >>= -(exp + 14);
        exp = -15;
    } else {
        /* underflow, make zero */
        return 0;
    }

    /* safe cast here as bit operations above guarantee not to overflow */
    return (unsigned short)(sign | ((exp + 15) << 10) | mant);


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5496057.3B1e02oPtX%40tjmaciei-mobl1.

.

------=_Part_379_666786968.1486668566476
Content-Type: multipart/alternative;
 boundary="----=_Part_380_391178010.1486668566476"

------=_Part_380_391178010.1486668566476
Content-Type: text/plain; charset=UTF-8

On Thursday, February 9, 2017 at 7:12:40 PM UTC+1, Thiago Macieira wrote:
>
>
> We used to have this problem with Clang: for example,
> qCountTrailingZeroBits
> wasn't constexpr with Clang until 3.8, because we couldn't use
> __builtin_ctz
> in a constexpr context.
>

That is inaccurate: builtin bit-twiddling in constexpr contexts has been
supported since Clang 3.4.

int main()
{
    static_assert(__builtin_ctz(0x8) == 3, "");
}

http://melpon.org/wandbox/permlink/atER2z2uVzSPxzjA

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/24bee7ba-de92-49e5-b5c0-e033f4b86f89%40isocpp.org.

------=_Part_380_391178010.1486668566476
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 9, 2017 at 7:12:40 PM UTC+1, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>We used to =
have this problem with Clang: for example, qCountTrailingZeroBits=20
<br>wasn&#39;t constexpr with Clang until 3.8, because we couldn&#39;t use =
__builtin_ctz=20
<br>in a constexpr context.
<br></blockquote><div><br></div><div>That is inaccurate: builtin bit-twiddl=
ing in constexpr contexts has been supported since Clang 3.4.=C2=A0</div><d=
iv><br></div><div>int main()</div><div>{</div><div>=C2=A0 =C2=A0 static_ass=
ert(__builtin_ctz(0x8) =3D=3D 3, &quot;&quot;);</div><div>}</div><div><br><=
/div><div>http://melpon.org/wandbox/permlink/atER2z2uVzSPxzjA=C2=A0</div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/24bee7ba-de92-49e5-b5c0-e033f4b86f89%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24bee7ba-de92-49e5-b5c0-e033f4b86f89=
%40isocpp.org</a>.<br />

------=_Part_380_391178010.1486668566476--

------=_Part_379_666786968.1486668566476--

.

On quinta-feira, 9 de fevereiro de 2017 11:29:26 PST rhalbersma@gmail.com
wrote:
> That is inaccurate: builtin bit-twiddling in constexpr contexts has been
> supported since Clang 3.4.
>
> int main()
> {
>     static_assert(__builtin_ctz(0x8) == 3, "");
> }
>
> http://melpon.org/wandbox/permlink/atER2z2uVzSPxzjA

Well, experience proves you wrong. This used to fail with Clang that came with
Xcode 6.4, which says:

Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)

So unless Apple broke something, then 3.5 didn't work.

(Testing with gcc.godbolt.org shows that it's actually Apple's fault)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1707568.ZBltNqqEby%40tjmaciei-mobl1.

.

--001a1142a430faf26005481e917e
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 9, 2017 at 9:04 PM, Thiago Macieira <thiago@macieira.org> wrote:

> On quinta-feira, 9 de fevereiro de 2017 11:29:26 PST rhalbersma@gmail.com
> wrote:
> > That is inaccurate: builtin bit-twiddling in constexpr contexts has been
> > supported since Clang 3.4.
> >
> > int main()
> > {
> >     static_assert(__builtin_ctz(0x8) == 3, "");
> > }
> >
> > http://melpon.org/wandbox/permlink/atER2z2uVzSPxzjA
>
> Well, experience proves you wrong. This used to fail with Clang that came
> with
> Xcode 6.4, which says:
>
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
>
> So unless Apple broke something, then 3.5 didn't work.
>
> (Testing with gcc.godbolt.org shows that it's actually Apple's fault
>

On Linux, this has been working for at least 3 years now, too bad if XCode
didn't work out for you.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5WBAOZd-L9_sC7GQe8%2B7H26AxAxYB_87EDTTfGhM%3Djnvw%40mail.gmail.com.

--001a1142a430faf26005481e917e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Feb 9, 2017 at 9:04 PM, Thiago Macieira <span dir=3D"ltr">&lt;<=
a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On quinta-feira, 9=
 de fevereiro de 2017 11:29:26 PST <a href=3D"mailto:rhalbersma@gmail.com">=
rhalbersma@gmail.com</a><br>
wrote:<br>
<span class=3D"">&gt; That is inaccurate: builtin bit-twiddling in constexp=
r contexts has been<br>
&gt; supported since Clang 3.4.<br>
&gt;<br>
&gt; int main()<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 =C2=A0static_assert(__builtin_ctz(<wbr>0x8) =3D=3D 3, &qu=
ot;&quot;);<br>
&gt; }<br>
&gt;<br>
&gt; <a href=3D"http://melpon.org/wandbox/permlink/atER2z2uVzSPxzjA" rel=3D=
"noreferrer" target=3D"_blank">http://melpon.org/wandbox/<wbr>permlink/atER=
2z2uVzSPxzjA</a><br>
<br>
</span>Well, experience proves you wrong. This used to fail with Clang that=
 came with<br>
Xcode 6.4, which says:<br>
<br>
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)<br>
<br>
So unless Apple broke something, then 3.5 didn&#39;t work.<br>
<br>
(Testing with <a href=3D"http://gcc.godbolt.org" rel=3D"noreferrer" target=
=3D"_blank">gcc.godbolt.org</a> shows that it&#39;s actually Apple&#39;s fa=
ult<br></blockquote><div><br></div><div>On Linux, this has been working for=
 at least 3 years now, too bad if XCode didn&#39;t work out for you.=C2=A0<=
/div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGBGO5WBAOZd-L9_sC7GQe8%2B7H26AxAxYB=
_87EDTTfGhM%3Djnvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5WBAOZd=
-L9_sC7GQe8%2B7H26AxAxYB_87EDTTfGhM%3Djnvw%40mail.gmail.com</a>.<br />

--001a1142a430faf26005481e917e--

.

On quinta-feira, 9 de fevereiro de 2017 21:10:18 PST Rein Halbersma wrote:
> On Linux, this has been working for at least 3 years now, too bad if XCode
> didn't work out for you.

Xcode's Clang is the overwhelming majority of Clang users for Qt. Something
like a 1000:1 ratio of usage and I am guessing low.

Anyway, Apple stopped trying to claim that they follow any release. Since
Xcode 7, they no longer even show which SVN branch they released from. So we
simply now track the Xcode version, not the Clang version. In turn, that means
we almost never enable Clang features based on the upstream version anymore,
until we get a report from someone on FreeBSD two years down the line.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1596622.tQMUhp6PIN%40tjmaciei-mobl1.

.

------=_Part_627_1812467590.1486730138402
Content-Type: multipart/alternative;
 boundary="----=_Part_628_920934134.1486730138402"

------=_Part_628_920934134.1486730138402
Content-Type: text/plain; charset=UTF-8

Whether some version of clang did or did not support one particular
intrinsic inside constexpr functions is kind of irrelevant.

Do you know how many SSE vector intrinsics and vector types are supported
by the constant expression evaluators of clang, gcc, and msvc? None, don't
need to even mention AVX or anything more modern, just plain old 1999's
SSE.

Even if it was somehow possible to support all these intrinsics (which I
don't think will ever happen in practice), it is still impossible to
support inline assembly (+ cross-compiling).

As a consequence, constexpr will never be a zero cost abstraction, because
there will always be a set of programs for which it incurs an extra
run-time cost.

I am not arguing whether "if constepxr() {...}" or [[constexpr_alias(..)]]
are the best or only ways to solve the problem, but rather that this is a
real problem and these could be some solutions. They are probably not
perfect, so I'd really appreciate if we could focus into proposing either
new solutions, or finding flaws in the proposed ones.

One potential peril of [[constexpr_alias]] could be that it might introduce
a new way to create ODR issues.

A peril of "if constexpr()"-like solutions is that the compiler might want
to evaluate a block of a non constexpr function at compile-time, in which
case it could make sense to make "if constexpr()" also work in
non-constexpr functions, and to return true if the current
context/scope/block is being evaluated at compile-time, independently of
whether the outer function is or isn't being evaluated at compile-time.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b081db0-cc7b-4a5f-b9fe-b9f8ae7ab9f7%40isocpp.org.

------=_Part_628_920934134.1486730138402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Whether some version of clang did or did not support one p=
articular intrinsic inside constexpr functions is kind of irrelevant. <br><=
br>Do you know how many SSE vector intrinsics and vector types are supporte=
d by the constant expression evaluators of clang, gcc, and msvc? None, don&=
#39;t need to even mention AVX or anything more modern, just plain old 1999=
&#39;s SSE. =C2=A0<div><br>Even if it was somehow possible to support all t=
hese intrinsics (which I don&#39;t think will ever happen in practice), it =
is still impossible to support inline assembly (+ cross-compiling).<br><br>=
As a consequence, constexpr will never be a zero cost abstraction, because =
there will always be a set of programs for which it incurs an extra run-tim=
e cost.<br><br>I am not arguing whether &quot;if constepxr() {...}&quot; or=
 [[constexpr_alias(..)]] are the best or only ways to solve the problem, bu=
t rather that this is a real problem and these could be some solutions. The=
y are probably not perfect, so I&#39;d really appreciate if we could focus =
into proposing either new solutions, or finding flaws in the proposed ones.=
<br><br>One potential peril of [[constexpr_alias]] could be that it might i=
ntroduce a new way to create ODR issues. <br><br>A peril of &quot;if conste=
xpr()&quot;-like solutions is that the compiler might want to evaluate a bl=
ock of a non constexpr function at compile-time, in which case it could mak=
e sense to make &quot;if constexpr()&quot; also work in non-constexpr funct=
ions, and to return true if the current context/scope/block is being evalua=
ted at compile-time, independently of whether the outer function is or isn&=
#39;t being evaluated at compile-time.=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5b081db0-cc7b-4a5f-b9fe-b9f8ae7ab9f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5b081db0-cc7b-4a5f-b9fe-b9f8ae7ab9f7=
%40isocpp.org</a>.<br />

------=_Part_628_920934134.1486730138402--

------=_Part_627_1812467590.1486730138402--

.

------=_Part_799_139306248.1486740488864
Content-Type: multipart/alternative;
 boundary="----=_Part_800_1015040977.1486740488864"

------=_Part_800_1015040977.1486740488864
Content-Type: text/plain; charset=UTF-8

On Friday, February 10, 2017 at 7:35:38 AM UTC-5, Gonzalo BG wrote:
>
> A peril of "if constexpr()"-like solutions is that the compiler might want
> to evaluate a block of a non constexpr function at compile-time, in which
> case it could make sense to make "if constexpr()" also work in
> non-constexpr functions, and to return true if the current
> context/scope/block is being evaluated at compile-time, independently of
> whether the outer function is or isn't being evaluated at compile-time.
>

I'm not sure what would keep `if constexpr()` from working under those
circumstances. You would simply define it to work if the compiler chooses
to execute the function at compile time.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a461e0af-67a6-491e-896f-c5d23826d407%40isocpp.org.

------=_Part_800_1015040977.1486740488864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 10, 2017 at 7:35:38 AM UTC-5, Gonzalo =
BG wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>A peril of &quot;if constexpr()&quot;-like solutions is that the compiler =
might want to evaluate a block of a non constexpr function at compile-time,=
 in which case it could make sense to make &quot;if constexpr()&quot; also =
work in non-constexpr functions, and to return true if the current context/=
scope/block is being evaluated at compile-time, independently of whether th=
e outer function is or isn&#39;t being evaluated at compile-time.</div></di=
v></blockquote><div><br>I&#39;m not sure what would keep `if constexpr()` f=
rom working under those circumstances. You would simply define it to work i=
f the compiler chooses to execute the function at compile time.<br></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a461e0af-67a6-491e-896f-c5d23826d407%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a461e0af-67a6-491e-896f-c5d23826d407=
%40isocpp.org</a>.<br />

------=_Part_800_1015040977.1486740488864--

------=_Part_799_139306248.1486740488864--

.

Em sexta-feira, 10 de fevereiro de 2017, =C3=A0s 04:35:38 PST, Gonzalo BG e=
screveu:
> Do you know how many SSE vector intrinsics and vector types are supported
> by the constant expression evaluators of clang, gcc, and msvc? None, don'=
t
> need to even mention AVX or anything more modern, just plain old 1999's
> SSE.

Of course.

But in our experience, any algorithm that can be complex enough to warrant=
=20
SIMD optimisation is too complex for a constexpr inline function. We don't=
=20
have any example of that in Qt code. All the ones that would need to be=20
constexpr and have a faster runtime have been so far solved by compiler=20
intrinsics.

The closest thing that would come to what you're saying is calculating a=20
string's hash. But we specifically *don't* want to have that inline so that=
 we=20
can change the algorithm later (right now, I'm considering changing the one=
 we=20
have based on CRC32 to one based on AES).

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6822781.nUHQ9xRxne%40tjmaciei-mobl1.

.

------=_Part_1004_293586593.1486838634069
Content-Type: multipart/alternative;
 boundary="----=_Part_1005_2054971813.1486838634069"

------=_Part_1005_2054971813.1486838634069
Content-Type: text/plain; charset=UTF-8

@Thiago:

> We used to have this problem with Clang: for example,
qCountTrailingZeroBits  wasn't constexpr with Clang until 3.8, because we
couldn't use __builtin_ctz  in a constexpr context.

Given that you have run into the issue, I cannot find the logic in the
following statement:

> But in our experience, any algorithm that can be complex enough to
warrant SIMD optimisation is too complex for a constexpr inline function.

You seem to be arguing that using __builtin_ctz in a constexpr function is
reasonable, but using any other intrinsics while solving problems in any
other domain is not. Care to elaborate on which experience makes you say so?

I am not a Qt user, but at least outside from Qt it is easy to find
examples of algorithms that are useful in constexpr functions, but for
which one always wants to use intrinsics/SIMD at run-time:

1) The post C++11 standard library. Before C++11 I rarely saw people
reimplementing pow, log, exp, sin, ... After C++11 almost every single
project had its own pow constexpr implementation because neither the math
functions from the standard library nor the builtins provided by the
compilers worked inside constant expressions for years after C++11. The
run-time performance of these functions was, and still is, horrible. The
fix for this was to make the math functions in the standard constexpr, but
this did not solve the underlying issue (which is being discussed here).

2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have used
expression template hacks for compile-time computations for the last 20
years _cannot_ use constexpr anywhere in their API (and don't really use it
almost anywhere) because somewhere down the pipeline they do use intrinsics
(and pragmas and what not) for run-time performance reasons.

Do you consider using a log function (which is implemented using intrinsics
in most standard libraries) or multiplying two 4x4 matrices "too complex"
for constexpr functions?

@Nicol Bolas:

> I'm not sure what would keep `if constexpr()` from working under those
circumstances. You would simply define it to work if the compiler chooses
to execute the function at compile time

I am quoting Eric from this issue which mentions ODR violations as a
potential issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452

>There are definitely opportunities for ODR violations here, or at least
>something like them. Consider the following case:
>
>template <class T>
>constexpr bool foo(T) {
>  if constexpr(__ctfe__)
>    return true;
>  else
>    return false
>}
>
>static_assert(foo(0));
>auto runtime = foo(0);
>
>Both calls instantiate foo with the same template arguments, so they should
>seemingly both get the same instantiation with the w/e value of `__ctfe__`
was
>when the implicit instantiations occurred. Therefore one of the two calls
to
>foo() will return the wrong answer.
>
>This problem is made ever worse if `__builtin_constant_expression` allows
you
>to generate non-dependent compile-time expressions based on the function
>arguments.
>
>One solution would be to consider the instantiation of `foo` to be value
>dependent on a "implicit template parameter" representing `__ctfe__`.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34826fd2-84db-4ce9-b30b-66a95601918a%40isocpp.org.

------=_Part_1005_2054971813.1486838634069
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>@Thiago:</div><div><br></div><div>&gt; We used to hav=
e this problem with Clang: for example, qCountTrailingZeroBits =C2=A0wasn&#=
39;t constexpr with Clang until 3.8, because we couldn&#39;t use __builtin_=
ctz=C2=A0=C2=A0in a constexpr context.=C2=A0</div><div><br></div><div>Given=
 that you have run into the issue, I cannot find the logic in the following=
 statement:<br></div><div><br></div>&gt; But in our experience, any algorit=
hm that can be complex enough to warrant=C2=A0SIMD optimisation is too comp=
lex for a constexpr inline function.<div><br></div><div>You seem to be argu=
ing that using __builtin_ctz in a constexpr function is reasonable, but usi=
ng any other intrinsics while solving problems in any other domain is not. =
Care to elaborate on which experience makes you say so?<br><br></div><div>I=
 am not a Qt user, but at least outside from Qt it is easy to find examples=
 of algorithms that are useful in constexpr functions, but for which one al=
ways wants to use intrinsics/SIMD at run-time:</div><div><br></div><div>1) =
The post C++11 standard library. Before C++11 I rarely saw people reimpleme=
nting pow, log, exp, sin, ... After C++11 almost every single project had i=
ts own pow constexpr implementation because neither the math functions from=
 the standard library nor the builtins provided by the compilers worked ins=
ide constant expressions for years after C++11. The run-time performance of=
 these functions was, and still is, horrible. The fix for this was to make =
the math functions in the standard constexpr, but this did not solve the un=
derlying issue (which is being discussed here).<br><br>2) Math/Linear algeb=
ra libraries like Eigen3, Blaze, ... which have used expression template ha=
cks for compile-time computations for the last 20 years _cannot_ use conste=
xpr anywhere in their API (and don&#39;t really use it almost anywhere) bec=
ause somewhere down the pipeline they do use intrinsics (and pragmas and wh=
at not) for run-time performance reasons.<br></div><div><br></div><div>Do y=
ou consider using a log function (which is implemented using intrinsics in =
most standard libraries) or multiplying two 4x4 matrices &quot;too complex&=
quot; for constexpr functions?</div><div><br></div><div>@Nicol Bolas:</div>=
<div><br></div><div>&gt; I&#39;m not sure what would keep `if constexpr()` =
from working under those circumstances. You would simply define it to work =
if the compiler chooses to execute the function at compile time</div><div><=
br></div><div>I am quoting Eric from this issue which mentions ODR violatio=
ns as a potential issue:=C2=A0https://gcc.gnu.org/bugzilla/show_bug.cgi?id=
=3D79452</div><div><br></div><div>&gt;<span style=3D"font-family: arial, sa=
ns-serif; font-size: 12.8px;">There are definitely opportunities for ODR vi=
olations here, or at least</span></div><span style=3D"font-family: arial, s=
ans-serif; font-size: 12.8px;">&gt;something like them. Consider the follow=
ing case:</span><br style=3D"font-family: arial, sans-serif; font-size: 12.=
8px;">&gt;<br style=3D"font-family: arial, sans-serif; font-size: 12.8px;">=
<span style=3D"font-family: arial, sans-serif; font-size: 12.8px;">&gt;temp=
late &lt;class T&gt;</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: =
12.8px;">&gt;constexpr bool foo(T) {</span><br style=3D"font-family: arial,=
 sans-serif; font-size: 12.8px;"><span style=3D"font-family: arial, sans-se=
rif; font-size: 12.8px;">&gt; =C2=A0if constexpr(__ctfe__)</span><br style=
=3D"font-family: arial, sans-serif; font-size: 12.8px;"><span style=3D"font=
-family: arial, sans-serif; font-size: 12.8px;">&gt; =C2=A0 =C2=A0return tr=
ue;</span><br style=3D"font-family: arial, sans-serif; font-size: 12.8px;">=
<span style=3D"font-family: arial, sans-serif; font-size: 12.8px;">&gt; =C2=
=A0else</span><br style=3D"font-family: arial, sans-serif; font-size: 12.8p=
x;"><span style=3D"font-family: arial, sans-serif; font-size: 12.8px;">&gt;=
 =C2=A0 =C2=A0return false</span><br style=3D"font-family: arial, sans-seri=
f; font-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-=
size: 12.8px;">&gt;}</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.8px;">&gt;<br style=3D"font-family: arial, sans-serif; font-size=
: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.8px=
;">&gt;static_assert(foo(0));</span><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; fo=
nt-size: 12.8px;">&gt;auto runtime =3D foo(0);</span><br style=3D"font-fami=
ly: arial, sans-serif; font-size: 12.8px;">&gt;<br style=3D"font-family: ar=
ial, sans-serif; font-size: 12.8px;"><span style=3D"font-family: arial, san=
s-serif; font-size: 12.8px;">&gt;Both calls instantiate foo with the same t=
emplate arguments, so they should</span><br style=3D"font-family: arial, sa=
ns-serif; font-size: 12.8px;"><span style=3D"font-family: arial, sans-serif=
; font-size: 12.8px;">&gt;seemingly both get the same instantiation with th=
e w/e value of `__ctfe__` was</span><br style=3D"font-family: arial, sans-s=
erif; font-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; fo=
nt-size: 12.8px;">&gt;when the implicit instantiations occurred. Therefore =
one of the two calls to</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-siz=
e: 12.8px;">&gt;foo() will return the wrong answer.</span><br style=3D"font=
-family: arial, sans-serif; font-size: 12.8px;">&gt;<br style=3D"font-famil=
y: arial, sans-serif; font-size: 12.8px;"><span style=3D"font-family: arial=
, sans-serif; font-size: 12.8px;">&gt;This problem is made ever worse if `_=
_builtin_constant_</span><wbr style=3D"font-family: arial, sans-serif; font=
-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: 1=
2.8px;">expression` allows you</span><br style=3D"font-family: arial, sans-=
serif; font-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; f=
ont-size: 12.8px;">&gt;to generate non-dependent compile-time expressions b=
ased on the function</span><br style=3D"font-family: arial, sans-serif; fon=
t-size: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: =
12.8px;">&gt;arguments.</span><br style=3D"font-family: arial, sans-serif; =
font-size: 12.8px;">&gt;<br style=3D"font-family: arial, sans-serif; font-s=
ize: 12.8px;"><span style=3D"font-family: arial, sans-serif; font-size: 12.=
8px;">&gt;One solution would be to consider the instantiation of `foo` to b=
e value</span><br style=3D"font-family: arial, sans-serif; font-size: 12.8p=
x;"><span style=3D"font-family: arial, sans-serif; font-size: 12.8px;">&gt;=
dependent on a &quot;implicit template parameter&quot; representing `__ctfe=
__`.</span></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34826fd2-84db-4ce9-b30b-66a95601918a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34826fd2-84db-4ce9-b30b-66a95601918a=
%40isocpp.org</a>.<br />

------=_Part_1005_2054971813.1486838634069--

------=_Part_1004_293586593.1486838634069--

.

On s=C3=A1bado, 11 de fevereiro de 2017 10:43:53 PST Gonzalo BG wrote:
> @Thiago:
> > We used to have this problem with Clang: for example,
> > qCountTrailingZeroBits  wasn't constexpr with Clang until 3.8, because =
we
> > couldn't use __builtin_ctz  in a constexpr context.
>=20
> Given that you have run into the issue, I cannot find the logic in the
>=20
> following statement:
> > But in our experience, any algorithm that can be complex enough to
> > warrant SIMD optimisation is too complex for a constexpr inline functio=
n.
>=20
> You seem to be arguing that using __builtin_ctz in a constexpr function i=
s
> reasonable, but using any other intrinsics while solving problems in any
> other domain is not. Care to elaborate on which experience makes you say =
so?

It was a problem, but it's now fixed and we now can use the builtin that is=
=20
constexpr.

> 1) The post C++11 standard library. Before C++11 I rarely saw people
> reimplementing pow, log, exp, sin, ... After C++11 almost every single
> project had its own pow constexpr implementation because neither the math
> functions from the standard library nor the builtins provided by the
> compilers worked inside constant expressions for years after C++11. The
> run-time performance of these functions was, and still is, horrible. The
> fix for this was to make the math functions in the standard constexpr, bu=
t
> this did not solve the underlying issue (which is being discussed here).

That's an interesting example, but it doesn't match my experience. I haven'=
t=20
seen a lot of people need exponentiation and logarithm in constexpr constex=
ts.=20
In regular code, you simply rely on the optimiser propagating constants,=20
something compilers have done for a decade.

> 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have used
> expression template hacks for compile-time computations for the last 20
> years _cannot_ use constexpr anywhere in their API (and don't really use =
it
> almost anywhere) because somewhere down the pipeline they do use intrinsi=
cs
> (and pragmas and what not) for run-time performance reasons.

Same as above: I've never seen the need for those operations to appear in a=
=20
constexpr context in the first place. It is as I said: the majority of the=
=20
operations that benefit from non-constexpr'able code is too complex for=20
constexpr anyway.

> Do you consider using a log function (which is implemented using intrinsi=
cs
> in most standard libraries) or multiplying two 4x4 matrices "too complex"
> for constexpr functions?

Yes, in my experience.

Or, put another way, what use-case warrants storing the result of such an=
=20
operation in a constexpr variable? This is a real question, you probably kn=
ow=20
more cases than I do.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/18849693.bqFcfaDNcV%40tjmaciei-mobl1.

.

--001a114488307b319905484843fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Eigen and other expression tempaltes library don't perform computation at
compile time, they build a lazy representation of computations at compile
time so the actual computations are delayed.
I wrote a couple of such library and the only places where constexpr made
sense was optimizing matrix size computation when all dimensions where
constants.

log2 happens a bit in constexpr context becasue finding the closest power
of 2 is a task some code may requires. I had myself solved a 2x2 linear
system but not much more at compile time.

2017-02-11 21:35 GMT+01:00 Thiago Macieira <thiago@macieira.org>:

> On s=C3=A1bado, 11 de fevereiro de 2017 10:43:53 PST Gonzalo BG wrote:
> > @Thiago:
> > > We used to have this problem with Clang: for example,
> > > qCountTrailingZeroBits  wasn't constexpr with Clang until 3.8, becaus=
e
> we
> > > couldn't use __builtin_ctz  in a constexpr context.
> >
> > Given that you have run into the issue, I cannot find the logic in the
> >
> > following statement:
> > > But in our experience, any algorithm that can be complex enough to
> > > warrant SIMD optimisation is too complex for a constexpr inline
> function.
> >
> > You seem to be arguing that using __builtin_ctz in a constexpr function
> is
> > reasonable, but using any other intrinsics while solving problems in an=
y
> > other domain is not. Care to elaborate on which experience makes you sa=
y
> so?
>
> It was a problem, but it's now fixed and we now can use the builtin that =
is
> constexpr.
>
> > 1) The post C++11 standard library. Before C++11 I rarely saw people
> > reimplementing pow, log, exp, sin, ... After C++11 almost every single
> > project had its own pow constexpr implementation because neither the ma=
th
> > functions from the standard library nor the builtins provided by the
> > compilers worked inside constant expressions for years after C++11. The
> > run-time performance of these functions was, and still is, horrible. Th=
e
> > fix for this was to make the math functions in the standard constexpr,
> but
> > this did not solve the underlying issue (which is being discussed here)=
..
>
> That's an interesting example, but it doesn't match my experience. I
> haven't
> seen a lot of people need exponentiation and logarithm in constexpr
> constexts.
> In regular code, you simply rely on the optimiser propagating constants,
> something compilers have done for a decade.
>
> > 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have use=
d
> > expression template hacks for compile-time computations for the last 20
> > years _cannot_ use constexpr anywhere in their API (and don't really us=
e
> it
> > almost anywhere) because somewhere down the pipeline they do use
> intrinsics
> > (and pragmas and what not) for run-time performance reasons.
>
> Same as above: I've never seen the need for those operations to appear in=
 a
> constexpr context in the first place. It is as I said: the majority of th=
e
> operations that benefit from non-constexpr'able code is too complex for
> constexpr anyway.
>
> > Do you consider using a log function (which is implemented using
> intrinsics
> > in most standard libraries) or multiplying two 4x4 matrices "too comple=
x"
> > for constexpr functions?
>
> Yes, in my experience.
>
> Or, put another way, what use-case warrants storing the result of such an
> operation in a constexpr variable? This is a real question, you probably
> know
> more cases than I do.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/18849693.bqFcfaDNcV%40tjmaciei-mobl1.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOG9n2H1a8bcWpnU1_EjwAA-h_Bs44zRLOWatZX%3D-mFLT=
LhjkA%40mail.gmail.com.

--001a114488307b319905484843fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Eigen and other expression tempaltes library don=
&#39;t perform computation at compile time, they build a lazy representatio=
n of computations at compile time so the actual computations are delayed.<b=
r></div>I wrote a couple of such library and the only places where constexp=
r made sense was optimizing matrix size computation when all dimensions whe=
re constants. <br><br></div>log2 happens a bit in constexpr context becasue=
 finding the closest power of 2 is a task some code may requires. I had mys=
elf solved a 2x2 linear system but not much more at compile time.<br></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-02-11 21:35 =
GMT+01:00 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@ma=
cieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</span>:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">On s=C3=A1bado, 11 de fevereiro de 2017 10:43:53 P=
ST Gonzalo BG wrote:<br>
&gt; @Thiago:<br>
&gt; &gt; We used to have this problem with Clang: for example,<br>
&gt; &gt; qCountTrailingZeroBits=C2=A0 wasn&#39;t constexpr with Clang unti=
l 3.8, because we<br>
&gt; &gt; couldn&#39;t use __builtin_ctz=C2=A0 in a constexpr context.<br>
&gt;<br>
&gt; Given that you have run into the issue, I cannot find the logic in the=
<br>
&gt;<br>
&gt; following statement:<br>
&gt; &gt; But in our experience, any algorithm that can be complex enough t=
o<br>
&gt; &gt; warrant SIMD optimisation is too complex for a constexpr inline f=
unction.<br>
&gt;<br>
&gt; You seem to be arguing that using __builtin_ctz in a constexpr functio=
n is<br>
&gt; reasonable, but using any other intrinsics while solving problems in a=
ny<br>
&gt; other domain is not. Care to elaborate on which experience makes you s=
ay so?<br>
<br>
It was a problem, but it&#39;s now fixed and we now can use the builtin tha=
t is<br>
constexpr.<br>
<br>
&gt; 1) The post C++11 standard library. Before C++11 I rarely saw people<b=
r>
&gt; reimplementing pow, log, exp, sin, ... After C++11 almost every single=
<br>
&gt; project had its own pow constexpr implementation because neither the m=
ath<br>
&gt; functions from the standard library nor the builtins provided by the<b=
r>
&gt; compilers worked inside constant expressions for years after C++11. Th=
e<br>
&gt; run-time performance of these functions was, and still is, horrible. T=
he<br>
&gt; fix for this was to make the math functions in the standard constexpr,=
 but<br>
&gt; this did not solve the underlying issue (which is being discussed here=
).<br>
<br>
That&#39;s an interesting example, but it doesn&#39;t match my experience. =
I haven&#39;t<br>
seen a lot of people need exponentiation and logarithm in constexpr constex=
ts.<br>
In regular code, you simply rely on the optimiser propagating constants,<br=
>
something compilers have done for a decade.<br>
<br>
&gt; 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have us=
ed<br>
&gt; expression template hacks for compile-time computations for the last 2=
0<br>
&gt; years _cannot_ use constexpr anywhere in their API (and don&#39;t real=
ly use it<br>
&gt; almost anywhere) because somewhere down the pipeline they do use intri=
nsics<br>
&gt; (and pragmas and what not) for run-time performance reasons.<br>
<br>
Same as above: I&#39;ve never seen the need for those operations to appear =
in a<br>
constexpr context in the first place. It is as I said: the majority of the<=
br>
operations that benefit from non-constexpr&#39;able code is too complex for=
<br>
constexpr anyway.<br>
<br>
&gt; Do you consider using a log function (which is implemented using intri=
nsics<br>
&gt; in most standard libraries) or multiplying two 4x4 matrices &quot;too =
complex&quot;<br>
&gt; for constexpr functions?<br>
<br>
Yes, in my experience.<br>
<br>
Or, put another way, what use-case warrants storing the result of such an<b=
r>
operation in a constexpr variable? This is a real question, you probably kn=
ow<br>
more cases than I do.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/18849693.bqFcfaDNcV%40tjmaciei-mobl1"=
 rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/18849693.bqFcfaDNcV%<wbr>40tjmaciei-mobl1=
</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOG9n2H1a8bcWpnU1_EjwAA-h_Bs44zRLOWa=
tZX%3D-mFLTLhjkA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOG9n2H1a8bcWp=
nU1_EjwAA-h_Bs44zRLOWatZX%3D-mFLTLhjkA%40mail.gmail.com</a>.<br />

--001a114488307b319905484843fb--

.

------=_Part_1238_783278304.1486918520314
Content-Type: multipart/alternative;
 boundary="----=_Part_1239_731663133.1486918520315"

------=_Part_1239_731663133.1486918520315
Content-Type: text/plain; charset=UTF-8



On Saturday, February 11, 2017 at 7:43:54 PM UTC+1, Gonzalo BG wrote:
>
> @Thiago:
>
> > We used to have this problem with Clang: for example,
> qCountTrailingZeroBits  wasn't constexpr with Clang until 3.8, because we
> couldn't use __builtin_ctz  in a constexpr context.
>
> Given that you have run into the issue, I cannot find the logic in the
> following statement:
>
> > But in our experience, any algorithm that can be complex enough to
> warrant SIMD optimisation is too complex for a constexpr inline function.
>
> You seem to be arguing that using __builtin_ctz in a constexpr function is
> reasonable, but using any other intrinsics while solving problems in any
> other domain is not. Care to elaborate on which experience makes you say so?
>
> I am not a Qt user, but at least outside from Qt it is easy to find
> examples of algorithms that are useful in constexpr functions, but for
> which one always wants to use intrinsics/SIMD at run-time:
>
> 1) The post C++11 standard library. Before C++11 I rarely saw people
> reimplementing pow, log, exp, sin, ... After C++11 almost every single
> project had its own pow constexpr implementation because neither the math
> functions from the standard library nor the builtins provided by the
> compilers worked inside constant expressions for years after C++11. The
> run-time performance of these functions was, and still is, horrible. The
> fix for this was to make the math functions in the standard constexpr, but
> this did not solve the underlying issue (which is being discussed here).
>
> 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have used
> expression template hacks for compile-time computations for the last 20
> years _cannot_ use constexpr anywhere in their API (and don't really use it
> almost anywhere) because somewhere down the pipeline they do use intrinsics
> (and pragmas and what not) for run-time performance reasons.
>
> Do you consider using a log function (which is implemented using
> intrinsics in most standard libraries) or multiplying two 4x4 matrices "too
> complex" for constexpr functions?
>
> @Nicol Bolas:
>
> > I'm not sure what would keep `if constexpr()` from working under those
> circumstances. You would simply define it to work if the compiler chooses
> to execute the function at compile time
>
> I am quoting Eric from this issue which mentions ODR violations as a
> potential issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
>
> >There are definitely opportunities for ODR violations here, or at least
> >something like them. Consider the following case:
> >
> >template <class T>
> >constexpr bool foo(T) {
> >  if constexpr(__ctfe__)
> >    return true;
> >  else
> >    return false
> >}
> >
> >static_assert(foo(0));
> >auto runtime = foo(0);
> >
> >Both calls instantiate foo with the same template arguments, so they
> should
> >seemingly both get the same instantiation with the w/e value of
> `__ctfe__` was
> >when the implicit instantiations occurred. Therefore one of the two calls
> to
> >foo() will return the wrong answer.
> >
> >This problem is made ever worse if `__builtin_constant_expression`
> allows you
> >to generate non-dependent compile-time expressions based on the function
> >arguments.
> >
> >One solution would be to consider the instantiation of `foo` to be value
> >dependent on a "implicit template parameter" representing `__ctfe__`.
>

a) All function need have `inline` to be able use `constexpr`
b) At some point you know if you call in `constexpr` context or not.

Probably best solution for today is manual overloading:

int k = 6;

template<bool is_constexpr>
constexpr int bar(int i, int j)
{
  return 42 * j + i;
}

template<>
int bar<false>(int i, int j)
{
  return k * j + i;
}

template<bool is_constexpr>
constexpr int foo(int i, int j)
{
  return bar<is_constexpr>(i + j, j);
}

template<int i>
struct S
{
  int f() { return i; }
}

int main()
{
  int a = 5;
  S<foo<true>(1, 2)> b(4, 4);
  return foo<false>(a, b.f());
}


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7d50e45-6f87-4ec1-9c4b-d7f7a0087640%40isocpp.org.

------=_Part_1239_731663133.1486918520315
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, February 11, 2017 at 7:43:54 PM UTC+1=
, Gonzalo BG wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>@Thiago:</div><div><br></div><div>&gt; We used to have this prob=
lem with Clang: for example, qCountTrailingZeroBits =C2=A0wasn&#39;t conste=
xpr with Clang until 3.8, because we couldn&#39;t use __builtin_ctz=C2=A0=
=C2=A0in a constexpr context.=C2=A0</div><div><br></div><div>Given that you=
 have run into the issue, I cannot find the logic in the following statemen=
t:<br></div><div><br></div>&gt; But in our experience, any algorithm that c=
an be complex enough to warrant=C2=A0SIMD optimisation is too complex for a=
 constexpr inline function.<div><br></div><div>You seem to be arguing that =
using __builtin_ctz in a constexpr function is reasonable, but using any ot=
her intrinsics while solving problems in any other domain is not. Care to e=
laborate on which experience makes you say so?<br><br></div><div>I am not a=
 Qt user, but at least outside from Qt it is easy to find examples of algor=
ithms that are useful in constexpr functions, but for which one always want=
s to use intrinsics/SIMD at run-time:</div><div><br></div><div>1) The post =
C++11 standard library. Before C++11 I rarely saw people reimplementing pow=
, log, exp, sin, ... After C++11 almost every single project had its own po=
w constexpr implementation because neither the math functions from the stan=
dard library nor the builtins provided by the compilers worked inside const=
ant expressions for years after C++11. The run-time performance of these fu=
nctions was, and still is, horrible. The fix for this was to make the math =
functions in the standard constexpr, but this did not solve the underlying =
issue (which is being discussed here).<br><br>2) Math/Linear algebra librar=
ies like Eigen3, Blaze, ... which have used expression template hacks for c=
ompile-time computations for the last 20 years _cannot_ use constexpr anywh=
ere in their API (and don&#39;t really use it almost anywhere) because some=
where down the pipeline they do use intrinsics (and pragmas and what not) f=
or run-time performance reasons.<br></div><div><br></div><div>Do you consid=
er using a log function (which is implemented using intrinsics in most stan=
dard libraries) or multiplying two 4x4 matrices &quot;too complex&quot; for=
 constexpr functions?</div><div><br></div><div>@Nicol Bolas:</div><div><br>=
</div><div>&gt; I&#39;m not sure what would keep `if constexpr()` from work=
ing under those circumstances. You would simply define it to work if the co=
mpiler chooses to execute the function at compile time</div><div><br></div>=
<div>I am quoting Eric from this issue which mentions ODR violations as a p=
otential issue:=C2=A0<a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?i=
d=3D79452" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fs=
how_bug.cgi%3Fid%3D79452\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHYY-2uiDJj=
9iboRU0STHSgoSnh2g&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%=
3Fid%3D79452\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHYY-2uiDJj9iboRU0STHSg=
oSnh2g&#39;;return true;">https://gcc.gnu.org/<wbr>bugzilla/show_bug.cgi?id=
=3D79452</a></div><div><br></div><div>&gt;<span style=3D"font-family:arial,=
sans-serif;font-size:12.8px">There are definitely opportunities for ODR vio=
lations here, or at least</span></div><span style=3D"font-family:arial,sans=
-serif;font-size:12.8px">&gt;something like them. Consider the following ca=
se:</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;<=
br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"f=
ont-family:arial,sans-serif;font-size:12.8px">&gt;template &lt;class T&gt;<=
/span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span sty=
le=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;constexpr bool foo=
(T) {</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><sp=
an style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt; =C2=A0if co=
nstexpr(__ctfe__)</span><br style=3D"font-family:arial,sans-serif;font-size=
:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;=
 =C2=A0 =C2=A0return true;</span><br style=3D"font-family:arial,sans-serif;=
font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.=
8px">&gt; =C2=A0else</span><br style=3D"font-family:arial,sans-serif;font-s=
ize:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px">&=
gt; =C2=A0 =C2=A0return false</span><br style=3D"font-family:arial,sans-ser=
if;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:=
12.8px">&gt;}</span><br style=3D"font-family:arial,sans-serif;font-size:12.=
8px">&gt;<br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span =
style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;static_assert(f=
oo(0));</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><=
span style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;auto runti=
me =3D foo(0);</span><br style=3D"font-family:arial,sans-serif;font-size:12=
..8px">&gt;<br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span=
 style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;Both calls ins=
tantiate foo with the same template arguments, so they should</span><br sty=
le=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fa=
mily:arial,sans-serif;font-size:12.8px">&gt;seemingly both get the same ins=
tantiation with the w/e value of `__ctfe__` was</span><br style=3D"font-fam=
ily:arial,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,san=
s-serif;font-size:12.8px">&gt;when the implicit instantiations occurred. Th=
erefore one of the two calls to</span><br style=3D"font-family:arial,sans-s=
erif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-siz=
e:12.8px">&gt;foo() will return the wrong answer.</span><br style=3D"font-f=
amily:arial,sans-serif;font-size:12.8px">&gt;<br style=3D"font-family:arial=
,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;f=
ont-size:12.8px">&gt;This problem is made ever worse if `__builtin_constant=
_</span><span style=3D"font-family:arial,sans-serif;font-size:12.8px">expre=
ssion<wbr>` allows you</span><br style=3D"font-family:arial,sans-serif;font=
-size:12.8px"><span style=3D"font-family:arial,sans-serif;font-size:12.8px"=
>&gt;to generate non-dependent compile-time expressions based on the functi=
on</span><br style=3D"font-family:arial,sans-serif;font-size:12.8px"><span =
style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;arguments.</spa=
n><br style=3D"font-family:arial,sans-serif;font-size:12.8px">&gt;<br style=
=3D"font-family:arial,sans-serif;font-size:12.8px"><span style=3D"font-fami=
ly:arial,sans-serif;font-size:12.8px">&gt;One solution would be to consider=
 the instantiation of `foo` to be value</span><br style=3D"font-family:aria=
l,sans-serif;font-size:12.8px"><span style=3D"font-family:arial,sans-serif;=
font-size:12.8px">&gt;dependent on a &quot;implicit template parameter&quot=
; representing `__ctfe__`.</span></div></blockquote><div><br>a) All functio=
n need have `inline` to be able use `constexpr`<br>b) At some point you kno=
w if you call in `constexpr` context or not.<br><br>Probably best solution =
for today is manual overloading:<br><div style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> k </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">6</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> is_constexpr</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> bar</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> j</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">42</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> j </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">template</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">&lt;false&gt;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> k </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> j </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> is_constexpr</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> j</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ba=
r</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;is_co=
nstexpr&gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> j</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> j</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> S<br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 S</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">&lt;true&gt;</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> foo</span><span style=3D"color: #080;" class=3D"styled=
-by-prettify">&lt;false&gt;</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">());</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7d50e45-6f87-4ec1-9c4b-d7f7a0087640%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7d50e45-6f87-4ec1-9c4b-d7f7a0087640=
%40isocpp.org</a>.<br />

------=_Part_1239_731663133.1486918520315--

------=_Part_1238_783278304.1486918520314--

.

(No TOFU=C2=B9 please!!)

On 2017-02-09 10:24, Faisal Vali wrote:
> On Thu, Feb 9, 2017 at 7:19 AM, Gonzalo BG wrote:
>> AFAIK none of the major C++ compilers provide a way to detect whether a
>> constexpr function is being evaluated at compile-time.
>=20
> Whether the standardization committee will ever embrace it (following
> a paper), is quite another matter

Fortunately, it seems Daveed has already written that paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0595r0.html

(=C2=B9 https://en.wikipedia.org/wiki/Posting_style#Top-posting)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58A6032C.9020001%40gmail.com.

.

On Thu, Feb 16, 2017 at 1:53 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> (No TOFU=C2=B9 please!!)

sorry (happens occasionally when i'm in a rush :( )


>
> On 2017-02-09 10:24, Faisal Vali wrote:
>> On Thu, Feb 9, 2017 at 7:19 AM, Gonzalo BG wrote:
>>> AFAIK none of the major C++ compilers provide a way to detect whether a
>>> constexpr function is being evaluated at compile-time.
>>
>> Whether the standardization committee will ever embrace it (following
>> a paper), is quite another matter
>
> Fortunately, it seems Daveed has already written that paper:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0595r0.html

That's awesome - and reason for much optimism!


>
> (=C2=B9 https://en.wikipedia.org/wiki/Posting_style#Top-posting)
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/58A6032C.9020001%40gmail.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CABsSThoDs7D02UtrUOE1Ob49wNZC3gOa_%3DY%3Dbx2K3TU=
YTWKpfA%40mail.gmail.com.

.