Topic: Would SIMD consider signed overflow undefined?
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 19 Mar 2018 14:04:06 -0700 (PDT)
Raw View
------=_Part_13482_578962940.1521493446540
Content-Type: multipart/alternative;
boundary="----=_Part_13483_1912531345.1521493446540"
------=_Part_13483_1912531345.1521493446540
Content-Type: text/plain; charset="UTF-8"
Would the SIMD proposals consider signed integer overflow to be undefined?
SIMD programming uses a lot of tricks for performance, including things
like reinterpreting values as the "wrong" type, and abusing
two's-complement overflow mechanics. This is often done irrespective of
whether the result is ultimately considered signed or unsigned.
Melissa
--
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/ad2467ad-fc49-4e25-9550-3aeff9124d39%40isocpp.org.
------=_Part_13483_1912531345.1521493446540
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Would the SIMD proposals consider signed integer overflow =
to be undefined?<br><br>SIMD programming uses a lot of tricks for performan=
ce, including things like reinterpreting values as the "wrong" ty=
pe, and abusing two's-complement overflow mechanics.=C2=A0 This is ofte=
n done irrespective of whether the result is ultimately considered signed o=
r unsigned.<br><br>Melissa<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ad2467ad-fc49-4e25-9550-3aeff9124d39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad2467ad-fc49-4e25-9550-3aeff9124d39=
%40isocpp.org</a>.<br />
------=_Part_13483_1912531345.1521493446540--
------=_Part_13482_578962940.1521493446540--
.
Author: Mathias Gaunard <mathias@gaunard.com>
Date: Mon, 19 Mar 2018 21:22:26 +0000
Raw View
--000000000000fe4d670567ca8d06
Content-Type: text/plain; charset="UTF-8"
On 19 March 2018 at 21:04, Myriachan <myriachan@gmail.com> wrote:
> Would the SIMD proposals consider signed integer overflow to be undefined?
>
> SIMD programming uses a lot of tricks for performance, including things
> like reinterpreting values as the "wrong" type, and abusing
> two's-complement overflow mechanics. This is often done irrespective of
> whether the result is ultimately considered signed or unsigned.
>
>
The standard library should expose any functionality that any trick can
stay in the implementation without the user having to worry about it.
One example of a "trick" is that the value for true is usually the same as
-1. So you can implement `a.where(condition)++' as `a - condition'.
--
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-MHDV%2BYOKY2x%3DxGjLRaAztaABz4T0cR%3DY5%2B1MC_Pf_dg%40mail.gmail.com.
--000000000000fe4d670567ca8d06
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 1=
9 March 2018 at 21:04, Myriachan <span dir=3D"ltr"><<a href=3D"mailto:my=
riachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></span> wro=
te:<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">Would the SIMD propo=
sals consider signed integer overflow to be undefined?<br><br>SIMD programm=
ing uses a lot of tricks for performance, including things like reinterpret=
ing values as the "wrong" type, and abusing two's-complement =
overflow mechanics.=C2=A0 This is often done irrespective of whether the re=
sult is ultimately considered signed or unsigned.<br><br></div></blockquote=
><div><br></div><div><span style=3D"color:rgb(34,34,34);font-family:arial,s=
ans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;f=
ont-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:st=
art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
;background-color:rgb(255,255,255);text-decoration-style:initial;text-decor=
ation-color:initial;float:none;display:inline">The standard library should =
expose any functionality that any trick can stay in the implementation with=
out the user having to worry about it.</span><div style=3D"color:rgb(34,34,=
34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-var=
iant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spaci=
ng:normal;text-align:start;text-indent:0px;text-transform:none;white-space:=
normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color=
:initial">One example of a "trick" is that the value for true is =
usually the same as -1. So you can implement `a.where(condition)++' as =
`a - condition'.</div>=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" 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-MHDV%2BYOKY2x%3DxGjLRaAztaABz=
4T0cR%3DY5%2B1MC_Pf_dg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-M=
HDV%2BYOKY2x%3DxGjLRaAztaABz4T0cR%3DY5%2B1MC_Pf_dg%40mail.gmail.com</a>.<br=
/>
--000000000000fe4d670567ca8d06--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 19 Mar 2018 17:28:44 -0700
Raw View
On Monday, 19 March 2018 14:22:26 PDT Mathias Gaunard wrote:
> On 19 March 2018 at 21:04, Myriachan <myriachan@gmail.com> wrote:
> > Would the SIMD proposals consider signed integer overflow to be undefined?
> >
> > SIMD programming uses a lot of tricks for performance, including things
> > like reinterpreting values as the "wrong" type, and abusing
> > two's-complement overflow mechanics. This is often done irrespective of
> > whether the result is ultimately considered signed or unsigned.
>
> The standard library should expose any functionality that any trick can
> stay in the implementation without the user having to worry about it.
> One example of a "trick" is that the value for true is usually the same as
> -1. So you can implement `a.where(condition)++' as `a - condition'.
SSE2 through AVX2 lacks unsigned comparison ability, so the usual trick is
also to subtract INT_MIN from both sides and perform a signed comparison. This
is a clear underflow situation.
An implementation could hide that fact when abstracting the SIMD details, but
that's another story. Libraries like Eigen aren't low-level SIMD manipulation,
but more like implementing certain useful algorithms. I don't think you can
abstract low-level SIMD and still get the most performance (which is the point
of SIMD).
--
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/4279422.DS7DAC81Sj%40tjmaciei-mobl1.
.