Topic: A call to discuss asm in constexpr and constexpr <algorithm>
Author: Antony Polukhin <antoshkka@gmail.com>
Date: Wed, 18 Nov 2015 22:22:52 +0300
Raw View
--94eb2c07efa691622e0524d59164
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello,
The Problem
The Standard Library provides a great collection of algorithms, many of
which currently lack constexpr support. Consider the simple example:
#include <array>
#include <algorithm>
int main() {
// OK
constexpr std::array<char, 6> a { 'H', 'e', 'l', 'l', 'o' };
// Note: std::array::begin(), std::array::end() are constexpr in P0031R=
0
// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html
// Failures:
// * std::find is not constexpr
constexpr auto it =3D std::find(a.begin(), a.end(), 'H');
}
Main problem with functions from <algorithm> is that they could be
optimized using assembly. Currently constexpr can not deal with inline
assembly.
Let's discuss and share ideas on how to improve the situation.
Ideas
Here are the ideas I've been investigating. Impatient ones could jump right
to the 'Refinement' to see the idea I've stopped on.
-----------------------------------------------
IDEA #1
Create a trait that signals usage of function inside constexpr context:
`__is_constexpr_context` that returns true_type or false_type
EXAMPLE in pseudocode:
template <class It, class Value>
constexpr It find_impl(It begin, It end, const Value& v, true_type
/*constexpr*/);
template <class It, class Value>
It find_impl(It begin, It end, const Value& v, false_type /*constexpr*/);
template <class It, class Value>
constexpr It find(It begin, It end, const Value& v) {
return find_impl(begin, end, v, __is_constexpr_context{});
}
DRAWBACKS:
* Breaks ODR (This is probably one of the worst ideas ever)
* Potentially forces user to write two different implementations of functio=
n
-----------------------------------------------
IDEA #2
Allow overloads by constexpr.
EXAMPLE in pseudocode:
template <class It, class Value>
It find(It begin, It end, const Value& v);
template <class It, class Value>
constexpr It find(It begin, It end, const Value& v);
DRAWBACKS:
* forces user to write two different implementations of function
* C++ already has a lot of overload rules, adding new ones does not seem to
be a good idea. For example which overload to choose is not obvious in
following case:
template <class T> constexpr void foo(const T& );
void foo(int );
-----------------------------------------------
IDEA #3
Relax restrictions on constexpr, allow usage of assembly and goto in
constexpr functions.
DRAWBACKS:
* Providing such ability for cross-compilaton would be a huge amount of
work for the compiler developers. Compiler developers would be forced to
know how to evaluate assembly for a foreign platform. For example cross
compiling on x86 for ARM will require the compiler to evaluate ARM assembly
on x86.
-----------------------------------------------
IDEA #4
Mark the required function with constexpr and force the Standard Library
developers and compiler developers to implement more compiler intrinsics.
EXAMPLE in pseudocode:
template <class It, class Value>
constexpr It find(It begin, It end, const Value& v) {
return __builtin_find(begin, end, v);
}
DRAWBACKS:
* This will make the Standard Libraries less portable across compilers
(every compiler vendor has it's own naming schemes for intrinsics).
* This solution is also not usable by user (user would not be able to
create it's own assembly optimized constexpr function, because he has no
access to the compiler internals).
-----------------------------------------------
IDEA #5
Add an additional keyword, signaling that in a constexpr context only this
overload must be used.
EXAMPLE in pseudocode:
template <class T>
constexpr_only // <---- new keyword
int foo(const T& ); // overlaod #1
int foo(int ); // overlaod #2
constexpr int foo(float ); // overlaod #3
int main() {
constexpr int i0 =3D foo(1); // will call overlaod #1
constexpr int i1 =3D foo(1.0); // will call overlaod #1
constexpr int i2 =3D foo(1.0f); // will call overlaod #3
int i3 =3D foo(1LL); // will call overlaod #2
int i4 =3D foo(1.0f); // will call overlaod #3
}
DRAWBACKS:
* New keyword is not good.
* This idea also affects the overload rules and make them even more
confusing.
* Potentially forces user to write two different implementations of functio=
n
-----------------------------------------------
Refinement
I've stopped on idea #3. In attempt to simplify the compiler developers
work, I've applied additional restrictions to inline assembly.
I took additional care to not mention the asm in [expr.const], because asm
definition is implementation-defined (see [dcl.asm]).
The impact on the C++ Standard is following:
In [dcl.constexpr] remove the following requirements on constexpr function
body:
=E2=80=94 an asm-definition,
=E2=80=94 a goto statement,
In [expr.const] add the following to the list of the "would evaluate one of
the following expressions:"
=E2=80=94 a call to priviledged instruction, long jump instruction, softwar=
e
interruption or any other instruction that
produces results depending not only on input arguments [ Example: x86
instructions CPUID, RDRAND, RDSEED =E2=80=94 end example ].
-----------------------------------------------
Any suggestions or improvements are welcomed!
--=20
Best regards,
Antony Polukhin
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--94eb2c07efa691622e0524d59164
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>The Problem<br><br>The Standard Library prov=
ides a great collection of algorithms, many of which currently lack constex=
pr support. Consider the simple example:<br><br>#include <array><br>#=
include <algorithm><br>=C2=A0<br>int main() {<br>=C2=A0=C2=A0=C2=A0 /=
/ OK<br>=C2=A0=C2=A0=C2=A0 constexpr std::array<char, 6> a { 'H&#=
39;, 'e', 'l', 'l', 'o' };<br>=C2=A0=C2=A0=
=C2=A0 // Note: std::array::begin(), std::array::end() are constexpr in P00=
31R0<br>=C2=A0=C2=A0=C2=A0 // <a href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2015/p0031r0.html">http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2015/p0031r0.html</a><br><br>=C2=A0=C2=A0=C2=A0 // Failures:<br=
>=C2=A0=C2=A0=C2=A0 // * std::find is not constexpr<br>=C2=A0=C2=A0=C2=A0 c=
onstexpr auto it =3D std::find(a.begin(), a.end(), 'H');<br>}<br><b=
r>Main problem with functions from <algorithm> is that they could be =
optimized using assembly. Currently constexpr can not deal with inline asse=
mbly.<br><br>Let's discuss and share ideas on how to improve the situat=
ion.<br><br><br><br>Ideas<br>Here are the ideas I've been investigating=
.. Impatient ones could jump right to the 'Refinement' to see the id=
ea I've stopped on.<br>-----------------------------------------------<=
br>IDEA #1<br>Create a trait that signals usage of function inside constexp=
r context: `__is_constexpr_context` that returns true_type or false_type<br=
><br>EXAMPLE in pseudocode:<br><br>template <class It, class Value><b=
r>constexpr It find_impl(It begin, It end, const Value& v, true_type /*=
constexpr*/);<br><br>template <class It, class Value><br>It find_impl=
(It begin, It end, const Value& v, false_type /*constexpr*/);<br><br>te=
mplate <class It, class Value><br>constexpr It find(It begin, It end,=
const Value& v) {<br>=C2=A0=C2=A0=C2=A0 return find_impl(begin, end, v=
, __is_constexpr_context{});<br>}<br><br>DRAWBACKS:<br>* Breaks ODR (This i=
s probably one of the worst ideas ever)<br>* Potentially forces user to wri=
te two different implementations of function<br><br>-----------------------=
------------------------<br>IDEA #2<br>Allow overloads by constexpr.<br><br=
>EXAMPLE in pseudocode:<br><br>template <class It, class Value><br>It=
find(It begin, It end, const Value& v);<br><br>template <class It, =
class Value><br>constexpr It find(It begin, It end, const Value& v);=
<br><br>DRAWBACKS:<br>* forces user to write two different implementations =
of function<br>* C++ already has a lot of overload rules, adding new ones d=
oes not seem to be a good idea. For example which overload to choose is not=
obvious in following case:<br>template <class T> constexpr void foo(=
const T& );<br>void foo(int );<br><br>---------------------------------=
--------------<br>IDEA #3<br>Relax restrictions on constexpr, allow usage o=
f assembly and goto in constexpr functions.<br><br>DRAWBACKS:<br>* Providin=
g such ability for cross-compilaton would be a huge amount of work for the =
compiler developers. Compiler developers would be forced to know how to eva=
luate assembly for a foreign platform. For example cross compiling on x86 f=
or ARM will require the compiler to evaluate ARM assembly on x86.<br><br>--=
---------------------------------------------<br>IDEA #4<br>Mark the requir=
ed function with constexpr and force the Standard Library developers and co=
mpiler developers to implement more compiler intrinsics.<br><br>EXAMPLE in =
pseudocode:<br><br>template <class It, class Value><br>constexpr It f=
ind(It begin, It end, const Value& v) {<br>=C2=A0=C2=A0=C2=A0 return __=
builtin_find(begin, end, v);<br>}<br><br>DRAWBACKS:<br>* This will make the=
Standard Libraries less portable across compilers (every compiler vendor h=
as it's own naming schemes for intrinsics). <br>* This solution is also=
not usable by user (user would not be able to create it's own assembly=
optimized constexpr function, because he has no access to the compiler int=
ernals).<br><br>-----------------------------------------------<br>IDEA #5<=
br>Add an additional keyword, signaling that in a constexpr context only th=
is overload must be used.<br><br>EXAMPLE in pseudocode:<br><br>template <=
;class T><br>constexpr_only // <---- new keyword<br>=C2=A0=C2=A0=C2=
=A0 int foo(const T& ); // overlaod #1<br><br>int foo(int );=C2=A0 // o=
verlaod #2<br>constexpr int foo(float );=C2=A0 // overlaod #3<br><br>int ma=
in() {<br>=C2=A0=C2=A0=C2=A0 constexpr int i0 =3D foo(1); // will call over=
laod #1<br>=C2=A0=C2=A0=C2=A0 constexpr int i1 =3D foo(1.0); // will call o=
verlaod #1<br>=C2=A0=C2=A0=C2=A0 constexpr int i2 =3D foo(1.0f); // will ca=
ll overlaod #3<br><br>=C2=A0=C2=A0=C2=A0 int i3 =3D foo(1LL); // will call =
overlaod #2<br>=C2=A0=C2=A0=C2=A0 int i4 =3D foo(1.0f); // will call overla=
od #3<br>}<br><br>DRAWBACKS:<br>* New keyword is not good.<br>* This idea a=
lso affects the overload rules and make them even more confusing.<br>* Pote=
ntially forces user to write two different implementations of function<br>-=
----------------------------------------------<br><br><br>Refinement<br>I&#=
39;ve stopped on idea #3. In attempt to simplify the compiler developers wo=
rk, I've applied additional restrictions to inline assembly.<br>I took =
additional care to not mention the asm in [expr.const], because asm definit=
ion is implementation-defined (see [dcl.asm]).<br><br>The impact on the C++=
Standard is following:<br><br>In [dcl.constexpr] remove the following requ=
irements on constexpr function body:<br>=C2=A0=C2=A0=C2=A0 =E2=80=94 an asm=
-definition,<br>=C2=A0=C2=A0=C2=A0 =E2=80=94 a goto statement,<br><br>In [e=
xpr.const] add the following to the list of the "would evaluate one of=
the following expressions:"<br><br>=E2=80=94 a call to priviledged in=
struction, long jump instruction, software interruption or any other instru=
ction that<br>=C2=A0produces results depending not only on input arguments =
[ Example: x86 instructions CPUID, RDRAND, RDSEED =E2=80=94 end example ].<=
br><br>-----------------------------------------------<br><br>Any suggestio=
ns or improvements are welcomed!<br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature">Best regards,<br>Antony Polukhin</div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--94eb2c07efa691622e0524d59164--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 18 Nov 2015 21:39:34 +0100
Raw View
--001a1148e62ae5a89c0524d6a385
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I was working on this earlier in the year. Current design is:
constexpr R f(P1, P2, P3) {
... constexpr version ...
} else {
... non-constexpr version ...
}
Enjoy,
Andrew.
On Wed, Nov 18, 2015 at 8:22 PM, Antony Polukhin <antoshkka@gmail.com>
wrote:
> Hello,
>
> The Problem
>
> The Standard Library provides a great collection of algorithms, many of
> which currently lack constexpr support. Consider the simple example:
>
> #include <array>
> #include <algorithm>
>
> int main() {
> // OK
> constexpr std::array<char, 6> a { 'H', 'e', 'l', 'l', 'o' };
> // Note: std::array::begin(), std::array::end() are constexpr in
> P0031R0
> //
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html
>
> // Failures:
> // * std::find is not constexpr
> constexpr auto it =3D std::find(a.begin(), a.end(), 'H');
> }
>
> Main problem with functions from <algorithm> is that they could be
> optimized using assembly. Currently constexpr can not deal with inline
> assembly.
>
> Let's discuss and share ideas on how to improve the situation.
>
>
>
> Ideas
> Here are the ideas I've been investigating. Impatient ones could jump
> right to the 'Refinement' to see the idea I've stopped on.
> -----------------------------------------------
> IDEA #1
> Create a trait that signals usage of function inside constexpr context:
> `__is_constexpr_context` that returns true_type or false_type
>
> EXAMPLE in pseudocode:
>
> template <class It, class Value>
> constexpr It find_impl(It begin, It end, const Value& v, true_type
> /*constexpr*/);
>
> template <class It, class Value>
> It find_impl(It begin, It end, const Value& v, false_type /*constexpr*/);
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v) {
> return find_impl(begin, end, v, __is_constexpr_context{});
> }
>
> DRAWBACKS:
> * Breaks ODR (This is probably one of the worst ideas ever)
> * Potentially forces user to write two different implementations of
> function
>
> -----------------------------------------------
> IDEA #2
> Allow overloads by constexpr.
>
> EXAMPLE in pseudocode:
>
> template <class It, class Value>
> It find(It begin, It end, const Value& v);
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v);
>
> DRAWBACKS:
> * forces user to write two different implementations of function
> * C++ already has a lot of overload rules, adding new ones does not seem
> to be a good idea. For example which overload to choose is not obvious in
> following case:
> template <class T> constexpr void foo(const T& );
> void foo(int );
>
> -----------------------------------------------
> IDEA #3
> Relax restrictions on constexpr, allow usage of assembly and goto in
> constexpr functions.
>
> DRAWBACKS:
> * Providing such ability for cross-compilaton would be a huge amount of
> work for the compiler developers. Compiler developers would be forced to
> know how to evaluate assembly for a foreign platform. For example cross
> compiling on x86 for ARM will require the compiler to evaluate ARM assemb=
ly
> on x86.
>
> -----------------------------------------------
> IDEA #4
> Mark the required function with constexpr and force the Standard Library
> developers and compiler developers to implement more compiler intrinsics.
>
> EXAMPLE in pseudocode:
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v) {
> return __builtin_find(begin, end, v);
> }
>
> DRAWBACKS:
> * This will make the Standard Libraries less portable across compilers
> (every compiler vendor has it's own naming schemes for intrinsics).
> * This solution is also not usable by user (user would not be able to
> create it's own assembly optimized constexpr function, because he has no
> access to the compiler internals).
>
> -----------------------------------------------
> IDEA #5
> Add an additional keyword, signaling that in a constexpr context only thi=
s
> overload must be used.
>
> EXAMPLE in pseudocode:
>
> template <class T>
> constexpr_only // <---- new keyword
> int foo(const T& ); // overlaod #1
>
> int foo(int ); // overlaod #2
> constexpr int foo(float ); // overlaod #3
>
> int main() {
> constexpr int i0 =3D foo(1); // will call overlaod #1
> constexpr int i1 =3D foo(1.0); // will call overlaod #1
> constexpr int i2 =3D foo(1.0f); // will call overlaod #3
>
> int i3 =3D foo(1LL); // will call overlaod #2
> int i4 =3D foo(1.0f); // will call overlaod #3
> }
>
> DRAWBACKS:
> * New keyword is not good.
> * This idea also affects the overload rules and make them even more
> confusing.
> * Potentially forces user to write two different implementations of
> function
> -----------------------------------------------
>
>
> Refinement
> I've stopped on idea #3. In attempt to simplify the compiler developers
> work, I've applied additional restrictions to inline assembly.
> I took additional care to not mention the asm in [expr.const], because as=
m
> definition is implementation-defined (see [dcl.asm]).
>
> The impact on the C++ Standard is following:
>
> In [dcl.constexpr] remove the following requirements on constexpr functio=
n
> body:
> =E2=80=94 an asm-definition,
> =E2=80=94 a goto statement,
>
> In [expr.const] add the following to the list of the "would evaluate one
> of the following expressions:"
>
> =E2=80=94 a call to priviledged instruction, long jump instruction, softw=
are
> interruption or any other instruction that
> produces results depending not only on input arguments [ Example: x86
> instructions CPUID, RDRAND, RDSEED =E2=80=94 end example ].
>
> -----------------------------------------------
>
> Any suggestions or improvements are welcomed!
>
>
> --
> Best regards,
> Antony Polukhin
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1148e62ae5a89c0524d6a385
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was working on this earlier in the year.=C2=A0 Current d=
esign is:<div><br></div><div>=C2=A0 =C2=A0 constexpr R f(P1, P2, P3) {</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0... constexpr version ...</div><div>=C2=A0=
=C2=A0 } else {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0... non-constexpr ver=
sion ...</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>Enjoy,</div><di=
v>Andrew.<br></div><div><br></div><div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Wed, Nov 18, 2015 at 8:22 PM, Antony Polukhin <spa=
n dir=3D"ltr"><<a href=3D"mailto:antoshkka@gmail.com" target=3D"_blank">=
antoshkka@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Hello,<br><br>The Problem<br><br>The Standard Library pro=
vides a great collection of algorithms, many of which currently lack conste=
xpr support. Consider the simple example:<br><br>#include <array><br>=
#include <algorithm><br>=C2=A0<br>int main() {<br>=C2=A0=C2=A0=C2=A0 =
// OK<br>=C2=A0=C2=A0=C2=A0 constexpr std::array<char, 6> a { 'H&=
#39;, 'e', 'l', 'l', 'o' };<br>=C2=A0=C2=A0=
=C2=A0 // Note: std::array::begin(), std::array::end() are constexpr in P00=
31R0<br>=C2=A0=C2=A0=C2=A0 // <a href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2015/p0031r0.html" target=3D"_blank">http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html</a><br><br>=C2=A0=C2=A0=C2=
=A0 // Failures:<br>=C2=A0=C2=A0=C2=A0 // * std::find is not constexpr<br>=
=C2=A0=C2=A0=C2=A0 constexpr auto it =3D std::find(a.begin(), a.end(), '=
;H');<br>}<br><br>Main problem with functions from <algorithm> is=
that they could be optimized using assembly. Currently constexpr can not d=
eal with inline assembly.<br><br>Let's discuss and share ideas on how t=
o improve the situation.<br><br><br><br>Ideas<br>Here are the ideas I'v=
e been investigating. Impatient ones could jump right to the 'Refinemen=
t' to see the idea I've stopped on.<br>----------------------------=
-------------------<br>IDEA #1<br>Create a trait that signals usage of func=
tion inside constexpr context: `__is_constexpr_context` that returns true_t=
ype or false_type<br><br>EXAMPLE in pseudocode:<br><br>template <class I=
t, class Value><br>constexpr It find_impl(It begin, It end, const Value&=
amp; v, true_type /*constexpr*/);<br><br>template <class It, class Value=
><br>It find_impl(It begin, It end, const Value& v, false_type /*con=
stexpr*/);<br><br>template <class It, class Value><br>constexpr It fi=
nd(It begin, It end, const Value& v) {<br>=C2=A0=C2=A0=C2=A0 return fin=
d_impl(begin, end, v, __is_constexpr_context{});<br>}<br><br>DRAWBACKS:<br>=
* Breaks ODR (This is probably one of the worst ideas ever)<br>* Potentiall=
y forces user to write two different implementations of function<br><br>---=
--------------------------------------------<br>IDEA #2<br>Allow overloads =
by constexpr.<br><br>EXAMPLE in pseudocode:<br><br>template <class It, c=
lass Value><br>It find(It begin, It end, const Value& v);<br><br>tem=
plate <class It, class Value><br>constexpr It find(It begin, It end, =
const Value& v);<br><br>DRAWBACKS:<br>* forces user to write two differ=
ent implementations of function<br>* C++ already has a lot of overload rule=
s, adding new ones does not seem to be a good idea. For example which overl=
oad to choose is not obvious in following case:<br>template <class T>=
constexpr void foo(const T& );<br>void foo(int );<br><br>-------------=
----------------------------------<br>IDEA #3<br>Relax restrictions on cons=
texpr, allow usage of assembly and goto in constexpr functions.<br><br>DRAW=
BACKS:<br>* Providing such ability for cross-compilaton would be a huge amo=
unt of work for the compiler developers. Compiler developers would be force=
d to know how to evaluate assembly for a foreign platform. For example cros=
s compiling on x86 for ARM will require the compiler to evaluate ARM assemb=
ly on x86.<br><br>-----------------------------------------------<br>IDEA #=
4<br>Mark the required function with constexpr and force the Standard Libra=
ry developers and compiler developers to implement more compiler intrinsics=
..<br><br>EXAMPLE in pseudocode:<br><br>template <class It, class Value&g=
t;<br>constexpr It find(It begin, It end, const Value& v) {<br>=C2=A0=
=C2=A0=C2=A0 return __builtin_find(begin, end, v);<br>}<br><br>DRAWBACKS:<b=
r>* This will make the Standard Libraries less portable across compilers (e=
very compiler vendor has it's own naming schemes for intrinsics). <br>*=
This solution is also not usable by user (user would not be able to create=
it's own assembly optimized constexpr function, because he has no acce=
ss to the compiler internals).<br><br>-------------------------------------=
----------<br>IDEA #5<br>Add an additional keyword, signaling that in a con=
stexpr context only this overload must be used.<br><br>EXAMPLE in pseudocod=
e:<br><br>template <class T><br>constexpr_only // <---- new keywor=
d<br>=C2=A0=C2=A0=C2=A0 int foo(const T& ); // overlaod #1<br><br>int f=
oo(int );=C2=A0 // overlaod #2<br>constexpr int foo(float );=C2=A0 // overl=
aod #3<br><br>int main() {<br>=C2=A0=C2=A0=C2=A0 constexpr int i0 =3D foo(1=
); // will call overlaod #1<br>=C2=A0=C2=A0=C2=A0 constexpr int i1 =3D foo(=
1.0); // will call overlaod #1<br>=C2=A0=C2=A0=C2=A0 constexpr int i2 =3D f=
oo(1.0f); // will call overlaod #3<br><br>=C2=A0=C2=A0=C2=A0 int i3 =3D foo=
(1LL); // will call overlaod #2<br>=C2=A0=C2=A0=C2=A0 int i4 =3D foo(1.0f);=
// will call overlaod #3<br>}<br><br>DRAWBACKS:<br>* New keyword is not go=
od.<br>* This idea also affects the overload rules and make them even more =
confusing.<br>* Potentially forces user to write two different implementati=
ons of function<br>-----------------------------------------------<br><br><=
br>Refinement<br>I've stopped on idea #3. In attempt to simplify the co=
mpiler developers work, I've applied additional restrictions to inline =
assembly.<br>I took additional care to not mention the asm in [expr.const],=
because asm definition is implementation-defined (see [dcl.asm]).<br><br>T=
he impact on the C++ Standard is following:<br><br>In [dcl.constexpr] remov=
e the following requirements on constexpr function body:<br>=C2=A0=C2=A0=C2=
=A0 =E2=80=94 an asm-definition,<br>=C2=A0=C2=A0=C2=A0 =E2=80=94 a goto sta=
tement,<br><br>In [expr.const] add the following to the list of the "w=
ould evaluate one of the following expressions:"<br><br>=E2=80=94 a ca=
ll to priviledged instruction, long jump instruction, software interruption=
or any other instruction that<br>=C2=A0produces results depending not only=
on input arguments [ Example: x86 instructions CPUID, RDRAND, RDSEED =E2=
=80=94 end example ].<br><br>----------------------------------------------=
-<br><br>Any suggestions or improvements are welcomed!<span class=3D"HOEnZb=
"><font color=3D"#888888"><br><br clear=3D"all"><br>-- <br><div>Best regard=
s,<br>Antony Polukhin</div>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1148e62ae5a89c0524d6a385--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 18 Nov 2015 14:28:04 -0800
Raw View
--001a113f042ce453dc0524d827d9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 18, 2015 at 11:22 AM, Antony Polukhin <antoshkka@gmail.com>
wrote:
> Hello,
>
> The Problem
>
> The Standard Library provides a great collection of algorithms, many of
> which currently lack constexpr support. Consider the simple example:
>
> #include <array>
> #include <algorithm>
>
> int main() {
> // OK
> constexpr std::array<char, 6> a { 'H', 'e', 'l', 'l', 'o' };
> // Note: std::array::begin(), std::array::end() are constexpr in
> P0031R0
> //
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html
>
> // Failures:
> // * std::find is not constexpr
> constexpr auto it =3D std::find(a.begin(), a.end(), 'H');
> }
>
> Main problem with functions from <algorithm> is that they could be
> optimized using assembly. Currently constexpr can not deal with inline
> assembly.
>
> Let's discuss and share ideas on how to improve the situation.
>
>
>
> Ideas
> Here are the ideas I've been investigating. Impatient ones could jump
> right to the 'Refinement' to see the idea I've stopped on.
> -----------------------------------------------
> IDEA #1
> Create a trait that signals usage of function inside constexpr context:
> `__is_constexpr_context` that returns true_type or false_type
>
> EXAMPLE in pseudocode:
>
> template <class It, class Value>
> constexpr It find_impl(It begin, It end, const Value& v, true_type
> /*constexpr*/);
>
> template <class It, class Value>
> It find_impl(It begin, It end, const Value& v, false_type /*constexpr*/);
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v) {
> return find_impl(begin, end, v, __is_constexpr_context{});
> }
>
> DRAWBACKS:
> * Breaks ODR (This is probably one of the worst ideas ever)
> * Potentially forces user to write two different implementations of
> function
>
> -----------------------------------------------
> IDEA #2
> Allow overloads by constexpr.
>
> EXAMPLE in pseudocode:
>
> template <class It, class Value>
> It find(It begin, It end, const Value& v);
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v);
>
> DRAWBACKS:
> * forces user to write two different implementations of function
> * C++ already has a lot of overload rules, adding new ones does not seem
> to be a good idea. For example which overload to choose is not obvious in
> following case:
> template <class T> constexpr void foo(const T& );
> void foo(int );
>
> -----------------------------------------------
> IDEA #3
> Relax restrictions on constexpr, allow usage of assembly and goto in
> constexpr functions.
>
> DRAWBACKS:
> * Providing such ability for cross-compilaton would be a huge amount of
> work for the compiler developers. Compiler developers would be forced to
> know how to evaluate assembly for a foreign platform. For example cross
> compiling on x86 for ARM will require the compiler to evaluate ARM assemb=
ly
> on x86.
>
> -----------------------------------------------
> IDEA #4
> Mark the required function with constexpr and force the Standard Library
> developers and compiler developers to implement more compiler intrinsics.
>
This seems like the best approach. Note that the intrinsics need not be as
broad and complex as the one you specify below. Instead, I imagine this
would look more like:
template <class It, class Value>
constexpr It find(It begin, It end, const Value& v) {
return __builtin_find(begin, end, v);
}
constexpr char *find(char *begin, char *end, const char& v) {
void *p =3D memchr(begin, v, end - begin);
return p ? begin + __builtin_ptrdiff(p, begin) : end;
}
EXAMPLE in pseudocode:
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v) {
> return __builtin_find(begin, end, v);
> }
>
> DRAWBACKS:
> * This will make the Standard Libraries less portable across compilers
> (every compiler vendor has it's own naming schemes for intrinsics).
> * This solution is also not usable by user (user would not be able to
> create it's own assembly optimized constexpr function, because he has no
> access to the compiler internals).
>
> -----------------------------------------------
> IDEA #5
> Add an additional keyword, signaling that in a constexpr context only thi=
s
> overload must be used.
>
> EXAMPLE in pseudocode:
>
> template <class T>
> constexpr_only // <---- new keyword
> int foo(const T& ); // overlaod #1
>
> int foo(int ); // overlaod #2
> constexpr int foo(float ); // overlaod #3
>
> int main() {
> constexpr int i0 =3D foo(1); // will call overlaod #1
> constexpr int i1 =3D foo(1.0); // will call overlaod #1
> constexpr int i2 =3D foo(1.0f); // will call overlaod #3
>
> int i3 =3D foo(1LL); // will call overlaod #2
> int i4 =3D foo(1.0f); // will call overlaod #3
> }
>
> DRAWBACKS:
> * New keyword is not good.
> * This idea also affects the overload rules and make them even more
> confusing.
> * Potentially forces user to write two different implementations of
> function
> -----------------------------------------------
>
>
> Refinement
> I've stopped on idea #3. In attempt to simplify the compiler developers
> work, I've applied additional restrictions to inline assembly.
> I took additional care to not mention the asm in [expr.const], because as=
m
> definition is implementation-defined (see [dcl.asm]).
>
> The impact on the C++ Standard is following:
>
> In [dcl.constexpr] remove the following requirements on constexpr functio=
n
> body:
> =E2=80=94 an asm-definition,
> =E2=80=94 a goto statement,
>
> In [expr.const] add the following to the list of the "would evaluate one
> of the following expressions:"
>
> =E2=80=94 a call to priviledged instruction, long jump instruction, softw=
are
> interruption or any other instruction that
> produces results depending not only on input arguments [ Example: x86
> instructions CPUID, RDRAND, RDSEED =E2=80=94 end example ].
>
> -----------------------------------------------
>
> Any suggestions or improvements are welcomed!
>
>
> --
> Best regards,
> Antony Polukhin
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a113f042ce453dc0524d827d9
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 W=
ed, Nov 18, 2015 at 11:22 AM, Antony Polukhin <span dir=3D"ltr"><<a href=
=3D"mailto:antoshkka@gmail.com" target=3D"_blank">antoshkka@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>The Pro=
blem<br><br>The Standard Library provides a great collection of algorithms,=
many of which currently lack constexpr support. Consider the simple exampl=
e:<br><br>#include <array><br>#include <algorithm><br>=C2=A0<br=
>int main() {<br>=C2=A0=C2=A0=C2=A0 // OK<br>=C2=A0=C2=A0=C2=A0 constexpr s=
td::array<char, 6> a { 'H', 'e', 'l', 'l&=
#39;, 'o' };<br>=C2=A0=C2=A0=C2=A0 // Note: std::array::begin(), st=
d::array::end() are constexpr in P0031R0<br>=C2=A0=C2=A0=C2=A0 // <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html" t=
arget=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0=
031r0.html</a><br><br>=C2=A0=C2=A0=C2=A0 // Failures:<br>=C2=A0=C2=A0=C2=A0=
// * std::find is not constexpr<br>=C2=A0=C2=A0=C2=A0 constexpr auto it =
=3D std::find(a.begin(), a.end(), 'H');<br>}<br><br>Main problem wi=
th functions from <algorithm> is that they could be optimized using a=
ssembly. Currently constexpr can not deal with inline assembly.<br><br>Let&=
#39;s discuss and share ideas on how to improve the situation.<br><br><br><=
br>Ideas<br>Here are the ideas I've been investigating. Impatient ones =
could jump right to the 'Refinement' to see the idea I've stopp=
ed on.<br>-----------------------------------------------<br>IDEA #1<br>Cre=
ate a trait that signals usage of function inside constexpr context: `__is_=
constexpr_context` that returns true_type or false_type<br><br>EXAMPLE in p=
seudocode:<br><br>template <class It, class Value><br>constexpr It fi=
nd_impl(It begin, It end, const Value& v, true_type /*constexpr*/);<br>=
<br>template <class It, class Value><br>It find_impl(It begin, It end=
, const Value& v, false_type /*constexpr*/);<br><br>template <class =
It, class Value><br>constexpr It find(It begin, It end, const Value&=
v) {<br>=C2=A0=C2=A0=C2=A0 return find_impl(begin, end, v, __is_constexpr_=
context{});<br>}<br><br>DRAWBACKS:<br>* Breaks ODR (This is probably one of=
the worst ideas ever)<br>* Potentially forces user to write two different =
implementations of function<br><br>----------------------------------------=
-------<br>IDEA #2<br>Allow overloads by constexpr.<br><br>EXAMPLE in pseud=
ocode:<br><br>template <class It, class Value><br>It find(It begin, I=
t end, const Value& v);<br><br>template <class It, class Value><b=
r>constexpr It find(It begin, It end, const Value& v);<br><br>DRAWBACKS=
:<br>* forces user to write two different implementations of function<br>* =
C++ already has a lot of overload rules, adding new ones does not seem to b=
e a good idea. For example which overload to choose is not obvious in follo=
wing case:<br>template <class T> constexpr void foo(const T& );<b=
r>void foo(int );<br><br>-----------------------------------------------<br=
>IDEA #3<br>Relax restrictions on constexpr, allow usage of assembly and go=
to in constexpr functions.<br><br>DRAWBACKS:<br>* Providing such ability fo=
r cross-compilaton would be a huge amount of work for the compiler develope=
rs. Compiler developers would be forced to know how to evaluate assembly fo=
r a foreign platform. For example cross compiling on x86 for ARM will requi=
re the compiler to evaluate ARM assembly on x86.<br><br>-------------------=
----------------------------<br>IDEA #4<br>Mark the required function with =
constexpr and force the Standard Library developers and compiler developers=
to implement more compiler intrinsics.<br></div></blockquote><div><br></di=
v><div>This seems like the best approach. Note that the intrinsics need not=
be as broad and complex as the one you specify below. Instead, I imagine t=
his would look more like:</div><div><br></div><div>template <class It, c=
lass Value><br>constexpr It find(It begin, It end, const Value& v) {=
<br>=C2=A0=C2=A0=C2=A0 return __builtin_find(begin, end, v);<br>}<br></div>=
<div><br></div><div>constexpr char *find(char *begin, char *end, const char=
& v) {</div><div>=C2=A0 =C2=A0 void *p =3D memchr(begin, v, end - begin=
);<br>=C2=A0=C2=A0=C2=A0 return p ? begin + __builtin_ptrdiff(p, begin) : e=
nd;<br>}<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">EXAMPLE =
in pseudocode:<br><br>template <class It, class Value><br>constexpr I=
t find(It begin, It end, const Value& v) {<br>=C2=A0=C2=A0=C2=A0 return=
__builtin_find(begin, end, v);<br>}<br><br>DRAWBACKS:<br>* This will make =
the Standard Libraries less portable across compilers (every compiler vendo=
r has it's own naming schemes for intrinsics). <br>* This solution is a=
lso not usable by user (user would not be able to create it's own assem=
bly optimized constexpr function, because he has no access to the compiler =
internals).<br><br>-----------------------------------------------<br>IDEA =
#5<br>Add an additional keyword, signaling that in a constexpr context only=
this overload must be used.<br><br>EXAMPLE in pseudocode:<br><br>template =
<class T><br>constexpr_only // <---- new keyword<br>=C2=A0=C2=A0=
=C2=A0 int foo(const T& ); // overlaod #1<br><br>int foo(int );=C2=A0 /=
/ overlaod #2<br>constexpr int foo(float );=C2=A0 // overlaod #3<br><br>int=
main() {<br>=C2=A0=C2=A0=C2=A0 constexpr int i0 =3D foo(1); // will call o=
verlaod #1<br>=C2=A0=C2=A0=C2=A0 constexpr int i1 =3D foo(1.0); // will cal=
l overlaod #1<br>=C2=A0=C2=A0=C2=A0 constexpr int i2 =3D foo(1.0f); // will=
call overlaod #3<br><br>=C2=A0=C2=A0=C2=A0 int i3 =3D foo(1LL); // will ca=
ll overlaod #2<br>=C2=A0=C2=A0=C2=A0 int i4 =3D foo(1.0f); // will call ove=
rlaod #3<br>}<br><br>DRAWBACKS:<br>* New keyword is not good.<br>* This ide=
a also affects the overload rules and make them even more confusing.<br>* P=
otentially forces user to write two different implementations of function<b=
r>-----------------------------------------------<br><br><br>Refinement<br>=
I've stopped on idea #3. In attempt to simplify the compiler developers=
work, I've applied additional restrictions to inline assembly.<br>I to=
ok additional care to not mention the asm in [expr.const], because asm defi=
nition is implementation-defined (see [dcl.asm]).<br><br>The impact on the =
C++ Standard is following:<br><br>In [dcl.constexpr] remove the following r=
equirements on constexpr function body:<br>=C2=A0=C2=A0=C2=A0 =E2=80=94 an =
asm-definition,<br>=C2=A0=C2=A0=C2=A0 =E2=80=94 a goto statement,<br><br>In=
[expr.const] add the following to the list of the "would evaluate one=
of the following expressions:"<br><br>=E2=80=94 a call to priviledged=
instruction, long jump instruction, software interruption or any other ins=
truction that<br>=C2=A0produces results depending not only on input argumen=
ts [ Example: x86 instructions CPUID, RDRAND, RDSEED =E2=80=94 end example =
].<br><br>-----------------------------------------------<br><br>Any sugges=
tions or improvements are welcomed!<span class=3D""><font color=3D"#888888"=
><br><br clear=3D"all"><br>-- <br><div>Best regards,<br>Antony Polukhin</di=
v>
</font></span></div><span class=3D""><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113f042ce453dc0524d827d9--
.
Author: rhalbersma@gmail.com
Date: Wed, 18 Nov 2015 14:34:04 -0800 (PST)
Raw View
------=_Part_1902_293656335.1447886044772
Content-Type: multipart/alternative;
boundary="----=_Part_1903_1830506738.1447886044772"
------=_Part_1903_1830506738.1447886044772
Content-Type: text/plain; charset=UTF-8
Clang currently allows bit-twiddling intrinsics (__builtin_popcount and
friends) in constant experssions. Is this a non-standard extension, or
don't these intrinsics use bit-twiddling asm under the hood?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1903_1830506738.1447886044772
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Clang currently allows bit-twiddling intrinsics (__builtin_popcount and friends) in constant experssions. Is this a non-standard extension, or don't these intrinsics use bit-twiddling asm under the hood?</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_1903_1830506738.1447886044772--
------=_Part_1902_293656335.1447886044772--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 18 Nov 2015 15:53:13 -0800
Raw View
--001a11c10f0270008f0524d95866
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 18, 2015 at 2:34 PM, <rhalbersma@gmail.com> wrote:
> Clang currently allows bit-twiddling intrinsics (__builtin_popcount and
> friends) in constant experssions. Is this a non-standard extension, or
> don't these intrinsics use bit-twiddling asm under the hood?
>
I don't understand the question. This is obviously a non-standard
extension; the standard has no __builtin_* functions. Under the hood, there
are usually two completely separate implementations of these for the case
when they're encountered during constant expression evaluation and the case
when code is generated for them.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c10f0270008f0524d95866
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 W=
ed, Nov 18, 2015 at 2:34 PM, <span dir=3D"ltr"><<a href=3D"mailto:rhalb=
ersma@gmail.com" target=3D"_blank">rhalbersma@gmail.com</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Clang currently allow=
s bit-twiddling intrinsics (__builtin_popcount and friends) in constant exp=
erssions. Is this a non-standard extension, or don't these intrinsics u=
se bit-twiddling asm under the hood?</div></blockquote><div><br></div><div>=
I don't understand the question. This is obviously a non-standard exten=
sion; the standard has no __builtin_* functions. Under the hood, there are =
usually two completely separate implementations of these for the case when =
they're encountered during constant expression evaluation and the case =
when code is generated for them.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c10f0270008f0524d95866--
.
Author: Antony Polukhin <antoshkka@gmail.com>
Date: Thu, 19 Nov 2015 23:17:49 +0300
Raw View
--001a11431cb0e823da0524ea7348
Content-Type: text/plain; charset=UTF-8
2015-11-18 23:39 GMT+03:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> I was working on this earlier in the year. Current design is:
>
> constexpr R f(P1, P2, P3) {
> ... constexpr version ...
> } else {
> ... non-constexpr version ...
> }
>
I think that approach was carefully avoided by the Standard Committee in
previous years, because it leads to reimplementation of the same function
in different ways which potentially leads to creation of hard detectable
errors.
--
Best regards,
Antony Polukhin
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11431cb0e823da0524ea7348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2015-11-18 23:39 GMT+03:00 Andrew Tomazos <span dir=3D"ltr"><<a href=3D"=
mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</=
a>></span>:<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"><div di=
r=3D"ltr">I was working on this earlier in the year.=C2=A0 Current design i=
s:<div><br></div><div>=C2=A0 =C2=A0 constexpr R f(P1, P2, P3) {</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0... constexpr version ...</div><div>=C2=A0 =C2=
=A0 } else {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0... non-constexpr version=
...</div><div>=C2=A0 =C2=A0 }</div></div></blockquote><div class=3D"gmail_=
extra"><br>I think that approach was carefully avoided by the Standard Comm=
ittee in previous years, because it leads to reimplementation of the same f=
unction in different ways which potentially leads to creation of hard detec=
table errors.<br></div></div><br>-- <br><div class=3D"gmail_signature">Best=
regards,<br>Antony Polukhin</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11431cb0e823da0524ea7348--
.
Author: Antony Polukhin <antoshkka@gmail.com>
Date: Thu, 19 Nov 2015 23:19:40 +0300
Raw View
--001a114c8270877b340524ea7a56
Content-Type: text/plain; charset=UTF-8
2015-11-19 1:28 GMT+03:00 Richard Smith <richard@metafoo.co.uk>:
>
> This seems like the best approach. Note that the intrinsics need not be as
> broad and complex as the one you specify below. Instead, I imagine this
> would look more like:
>
> template <class It, class Value>
> constexpr It find(It begin, It end, const Value& v) {
> return __builtin_find(begin, end, v);
> }
>
> constexpr char *find(char *begin, char *end, const char& v) {
> void *p = memchr(begin, v, end - begin);
> return p ? begin + __builtin_ptrdiff(p, begin) : end;
> }
>
This actually gave me an idea to split proposal into two parts:
* algorithm only related proposal, that could be implemented by vendors
using intrinsics (if required)
* proposal to allow asm in constexpr. This would untie hands for algorithms
implementation without intrinsics
For the curious, here's some draft version of the first proposal:
http://apolukhin.github.io/constexpr_algorithms/
--
Best regards,
Antony Polukhin
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114c8270877b340524ea7a56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2015-11-19 1:28 GMT+03:00 Richard Smith <span dir=3D"ltr"><<a href=3D"ma=
ilto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>>=
</span>:<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"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div><div><div class=3D"h5"><br></div></div>=
<div>This seems like the best approach. Note that the intrinsics need not b=
e as broad and complex as the one you specify below. Instead, I imagine thi=
s would look more like:</div><span class=3D""><div><br></div><div>template =
<class It, class Value><br>constexpr It find(It begin, It end, const =
Value& v) {<br>=C2=A0=C2=A0=C2=A0 return __builtin_find(begin, end, v);=
<br>}<br></div><div><br></div></span><div>constexpr char *find(char *begin,=
char *end, const char& v) {</div><div>=C2=A0 =C2=A0 void *p =3D memchr=
(begin, v, end - begin);<br>=C2=A0=C2=A0=C2=A0 return p ? begin + __builtin=
_ptrdiff(p, begin) : end;<br>}=C2=A0</div></div></div></div></blockquote></=
div><br>This actually gave me an idea to split proposal into two parts:<br>=
* algorithm only related proposal, that could be implemented by vendors usi=
ng intrinsics (if required)<br>* proposal to allow asm in constexpr. This w=
ould untie hands for algorithms implementation without intrinsics<br><br>Fo=
r the curious, here's some draft version of the first proposal: <a href=
=3D"http://apolukhin.github.io/constexpr_algorithms/">http://apolukhin.gith=
ub.io/constexpr_algorithms/</a><br clear=3D"all"><br>-- <br><div class=3D"g=
mail_signature">Best regards,<br>Antony Polukhin</div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a114c8270877b340524ea7a56--
.
Author: inkwizytoryankes@gmail.com
Date: Fri, 20 Nov 2015 10:35:03 -0800 (PST)
Raw View
------=_Part_1891_892087087.1448044504112
Content-Type: multipart/alternative;
boundary="----=_Part_1892_803786196.1448044504112"
------=_Part_1892_803786196.1448044504112
Content-Type: text/plain; charset=UTF-8
On Thursday, November 19, 2015 at 9:19:42 PM UTC+1, Antony Polukhin wrote:
>
>
> 2015-11-19 1:28 GMT+03:00 Richard Smith <ric...@metafoo.co.uk
> <javascript:>>:
>
>>
>> This seems like the best approach. Note that the intrinsics need not be
>> as broad and complex as the one you specify below. Instead, I imagine this
>> would look more like:
>>
>> template <class It, class Value>
>> constexpr It find(It begin, It end, const Value& v) {
>> return __builtin_find(begin, end, v);
>> }
>>
>> constexpr char *find(char *begin, char *end, const char& v) {
>> void *p = memchr(begin, v, end - begin);
>> return p ? begin + __builtin_ptrdiff(p, begin) : end;
>> }
>>
>
> This actually gave me an idea to split proposal into two parts:
> * algorithm only related proposal, that could be implemented by vendors
> using intrinsics (if required)
> * proposal to allow asm in constexpr. This would untie hands for
> algorithms implementation without intrinsics
>
> For the curious, here's some draft version of the first proposal:
> http://apolukhin.github.io/constexpr_algorithms/
>
> --
> Best regards,
> Antony Polukhin
>
I think that is impossible to support asm in constexpr. Consider this, I
have x86 machine compiling for Arm. What CPU should be supported in
constexpr function in that case?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1892_803786196.1448044504112
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, November 19, 2015 at 9:19:42 PM UTC+1, Antony Polukhin=
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><=
br><div class=3D"gmail_quote">2015-11-19 1:28 GMT+03:00 Richard Smith <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"HwFrNfYFBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">ric...@metafoo.co.uk</a>></span>:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><br></div><=
/div><div>This seems like the best approach. Note that the intrinsics need =
not be as broad and complex as the one you specify below. Instead, I imagin=
e this would look more like:</div><span><div><br></div><div>template <cl=
ass It, class Value><br>constexpr It find(It begin, It end, const Value&=
amp; v) {<br>=C2=A0=C2=A0=C2=A0 return __builtin_find(begin, end, v);<br>}<=
br></div><div><br></div></span><div>constexpr char *find(char *begin, char =
*end, const char& v) {</div><div>=C2=A0 =C2=A0 void *p =3D memchr(begin=
, v, end - begin);<br>=C2=A0=C2=A0=C2=A0 return p ? begin + __builtin_ptrdi=
ff(p, begin) : end;<br>}=C2=A0</div></div></div></div></blockquote></div><b=
r>This actually gave me an idea to split proposal into two parts:<br>* algo=
rithm only related proposal, that could be implemented by vendors using int=
rinsics (if required)<br>* proposal to allow asm in constexpr. This would u=
ntie hands for algorithms implementation without intrinsics<br><br>For the =
curious, here's some draft version of the first proposal: <a href=3D"ht=
tp://apolukhin.github.io/constexpr_algorithms/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fapolukhin.github.io%2Fconstexpr_algorithms%2F\46sa\75D\46sntz\0751\=
46usg\75AFQjCNGRC--bJduxgf_KQ4iXe5VTEYg4lA';return true;" onclick=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fapolukhin.github.=
io%2Fconstexpr_algorithms%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNGRC--bJduxg=
f_KQ4iXe5VTEYg4lA';return true;">http://apolukhin.github.io/<wbr>conste=
xpr_algorithms/</a><br clear=3D"all"><br>-- <br><div>Best regards,<br>Anton=
y Polukhin</div></div></div></blockquote><div>I think that is impossible to=
support asm in constexpr. Consider this, I have x86 machine compiling for =
Arm. What CPU should be supported in constexpr function in that case? <br><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1892_803786196.1448044504112--
------=_Part_1891_892087087.1448044504112--
.