Topic: P1246R0: The no_float function attribute
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 14 Oct 2018 22:28:43 -0700
Raw View
Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html
The paper proposes a new function attribute to prevent the generation of
floating point instructions by the compiler, clearly marking such a function.
I like the proposal, it's an interesting evolution.
I just have a few questions to the authors:
1) kernel implementations are usually the opposite: they use no floating
point by default, except in a few specific cases. Is the intention that every
function that doesn't use floating-point be marked? That seems like a recipe
for mistake, as it would be easy to forget to mark a few functions. Would it
be possible to provide a translation-unit-wide marker saying "none of these
functions require floating point"?
2) if there's a TU-wide marker, should there be an inverse attribute
"yes_float" (with a better name)?
3) I'm also not sure the name "no_float" is the best. As you note in point #4
of what it means to use such an attribute, an implementation-defined
consequence is that vectorisation should be suppressed as those use the same
registers as floating point. But that's not the case for all architectures,
x86 32-bit being the prime example. Therefore, "no_float" changing the code
generation for integral / byte-level operations could be surprising. Have you
received any other suggestions for a name? Possibly splitting the behaviour
between FP and integral vector codegen changes?
It's especially surprising that one would mark [[no_float]] functions that
already don't do floating point. It seems that kernel developers would be
abusing the attribute for its implementation-specific side-effects, instead of
the main purpose. And if one wants to deal with implementation-specific
effects, why should that be in the standard?
--
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/3924444.JBScVLu4Tn%40tjmaciei-mobl1.
.
Author: David Brown <david@westcontrol.com>
Date: Mon, 15 Oct 2018 11:17:17 +0200
Raw View
On 15/10/18 07:28, Thiago Macieira wrote:
> Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html
>
> The paper proposes a new function attribute to prevent the generation of
> floating point instructions by the compiler, clearly marking such a function.
> I like the proposal, it's an interesting evolution.
>
> I just have a few questions to the authors:
>
> 1) kernel implementations are usually the opposite: they use no floating
> point by default, except in a few specific cases. Is the intention that every
> function that doesn't use floating-point be marked? That seems like a recipe
> for mistake, as it would be easy to forget to mark a few functions. Would it
> be possible to provide a translation-unit-wide marker saying "none of these
> functions require floating point"?
>
> 2) if there's a TU-wide marker, should there be an inverse attribute
> "yes_float" (with a better name)?
>
I would say that what you want here is to be able to attach attributes
to namespaces, that would give the default setting for functions defined
in the namespace.
The alternative is the good old fashioned #pragma, which is great for
saying "everything from here onwards should be like this".
Either way, having a "yes_float" attribute is almost essential.
> 3) I'm also not sure the name "no_float" is the best. As you note in point #4
> of what it means to use such an attribute, an implementation-defined
> consequence is that vectorisation should be suppressed as those use the same
> registers as floating point. But that's not the case for all architectures,
> x86 32-bit being the prime example. Therefore, "no_float" changing the code
> generation for integral / byte-level operations could be surprising. Have you
> received any other suggestions for a name? Possibly splitting the behaviour
> between FP and integral vector codegen changes?
There could be many other attributes for code generation options, but it
is very hard to be universal about them - usually the will depend on the
target device. (Looking at gcc, there are a few common code generation
options that might be interesting as standard attributes - "wrapv" for
wrapping signed integer overflow, and "exceptions" for enabling or
disabling exception handling. Others are target specific.)
>
> It's especially surprising that one would mark [[no_float]] functions that
> already don't do floating point. It seems that kernel developers would be
> abusing the attribute for its implementation-specific side-effects, instead of
> the main purpose. And if one wants to deal with implementation-specific
> effects, why should that be in the standard?
>
Sometimes floating point registers and operations are used for other
purposes. For example, on 32-bit targets with 64-bit floating point
registers, floating point loads and stores can be used for more
efficient movement of data.
Another issue for an attribute like this is if it should be part of the
function declaration as well as the definition? If a function uses many
floating point registers, including the caller-saved ones, and calls an
external function then if it knows that function is no_float, it does
not need to stack and restore those registers.
And should a no_float function be allowed to call functions that are not
marked as no_float ?
--
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/pq1lqq%24qs6%241%40blaine.gmane.org.
.
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Mon, 15 Oct 2018 10:29:58 +0100
Raw View
--00000000000059493c05784115af
Content-Type: text/plain; charset="UTF-8"
>
> [snip]
>
> And should a no_float function be allowed to call functions that are not
> marked as no_float ?
>
> There is no way to enforce this over a link boundary, so it can't be used
for caller-saved FPU registers. Attributes are by definition not allowed to
change the behavior of the program in a way that would be incompatible,
should the be ignored. You might add error diagnostics though, and then
under the assumption that the same compiler that does not ignore these
attributes is used for all TUs in that call path, be reasonably sure that
[[no_float]] functions don't call anything that uses the FPU.
On the other hand, caller-saved registers only need to be saved and
restored if the function uses them, and a [[no_float]] function wouldn't be
doing that anyway. A [[yes_float]] function calling a [[no_float]] function
still has to abide by the ABI though, and save/restore the registers.
May I suggest the bikeshed of [[fpu(false)]] and [[fpu(true)]] instead of
[[no_float]] and [[yes_float]]? I think it might make it a bit more obvious
that it's not FP instructions, but the FP unit that you are vowing not to
use.
Or, alternatively, split this into a few separate attributes.
G
--
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/CAANG%3DkUyvwYT%2BFYiRzJkbsw5YRi3RcH4E1AmPED-fUUm%2BJ77xw%40mail.gmail.com.
--00000000000059493c05784115af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
[snip]<br>
<br>
And should a no_float function be allowed to call functions that are not<br=
>
marked as no_float ?<br><br></blockquote><div>There is no way to enforce th=
is over a link boundary, so it can't be used for caller-saved FPU regis=
ters. Attributes are by definition not allowed to change the behavior of th=
e program in a way that would be incompatible, should the be ignored. You m=
ight add error diagnostics though, and then under the assumption that the s=
ame compiler that does not ignore these attributes is used for all TUs in t=
hat call path, be reasonably sure that [[no_float]] functions don't cal=
l anything that uses the FPU.</div><div><br></div><div>On the other hand, c=
aller-saved registers only need to be saved and restored if the function us=
es them, and a [[no_float]] function wouldn't be doing that anyway. A [=
[yes_float]] function calling a [[no_float]] function still has to abide by=
the ABI though, and save/restore the registers.</div><div><br></div><div>M=
ay I suggest the bikeshed of [[fpu(false)]] and [[fpu(true)]] instead of [[=
no_float]] and [[yes_float]]? I think it might make it a bit more obvious t=
hat it's not FP instructions, but the FP unit that you are vowing not t=
o use.</div><div><br></div><div>Or, alternatively, split this into a few se=
parate attributes.</div><div><br></div><div>G</div><div><br></div><div><br>=
</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/CAANG%3DkUyvwYT%2BFYiRzJkbsw5YRi3RcH4=
E1AmPED-fUUm%2BJ77xw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUy=
vwYT%2BFYiRzJkbsw5YRi3RcH4E1AmPED-fUUm%2BJ77xw%40mail.gmail.com</a>.<br />
--00000000000059493c05784115af--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 15 Oct 2018 09:03:17 -0700
Raw View
On Monday, 15 October 2018 02:17:17 PDT David Brown wrote:
> > 1) kernel implementations are usually the opposite: they use no floating
> > point by default, except in a few specific cases. Is the intention that
> > every function that doesn't use floating-point be marked? That seems like
> > a recipe for mistake, as it would be easy to forget to mark a few
> > functions. Would it be possible to provide a translation-unit-wide marker
> > saying "none of these functions require floating point"?
> >
> > 2) if there's a TU-wide marker, should there be an inverse attribute
> > "yes_float" (with a better name)?
>
> I would say that what you want here is to be able to attach attributes
> to namespaces, that would give the default setting for functions defined
> in the namespace.
Only if you can apply such an attribute to the global namespace too. A lot of
code that would benefit from this new attribute is part of these massive,
massively-multithreaded single-process, freestanding applications called
"kernel" and those have very old codebases with no namespace.
> The alternative is the good old fashioned #pragma, which is great for
> saying "everything from here onwards should be like this".
Sounds like it.
--
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/2741605.V8WyXYXDNz%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 15 Oct 2018 09:08:03 -0700
Raw View
On Monday, 15 October 2018 02:29:58 PDT Ga=C5=A1per A=C5=BEman wrote:
> > [snip]
> >=20
> > And should a no_float function be allowed to call functions that are no=
t
> > marked as no_float ?
> >=20
> There is no way to enforce this over a link boundary, so it can't be used
> for caller-saved FPU registers. Attributes are by definition not allowed =
to
> change the behavior of the program in a way that would be incompatible,
> should the be ignored. You might add error diagnostics though, and then
> under the assumption that the same compiler that does not ignore these
> attributes is used for all TUs in that call path, be reasonably sure that
> [[no_float]] functions don't call anything that uses the FPU.
Attributes are not allowed to change the visible behaviour, but they are=20
intended to help the compiler optimise the code better. See [[noreturn]] fo=
r=20
an example. So a [[no_float]] attribute could let the compiler optimise by =
not=20
performing any caller-saved FP saving, as it knows the called function will=
=20
not directly or indirectly modify any FP register.
> On the other hand, caller-saved registers only need to be saved and
> restored if the function uses them, and a [[no_float]] function wouldn't =
be
> doing that anyway. A [[yes_float]] function calling a [[no_float]] functi=
on
> still has to abide by the ABI though, and save/restore the registers.
Interestingly, in calling [[yes_float]] from a [[no_float]], one of the two=
=20
must save the caller-saved registers. Since the [[no_float]] says it won't=
=20
touch them, it stands to reason that the callee takes on that responsibilit=
y.
In fact, that's what kernels usually do: they have a pair of functions or=
=20
macros that must be called before and after any FP-using code to save the=
=20
context from the user and then restore it.
--=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/2684534.kTBUrM6NSS%40tjmaciei-mobl1.
.
Author: JF Bastien <jfbastien@apple.com>
Date: Mon, 15 Oct 2018 10:29:36 -0700
Raw View
--Boundary_(ID_xe56jvUn6xsKmdT+LQZBTQ)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Oct 14, 2018, at 10:28 PM, Thiago Macieira <thiago@macieira.org> wrote=
:
>=20
> Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html
>=20
> The paper proposes a new function attribute to prevent the generation of=
=20
> floating point instructions by the compiler, clearly marking such a funct=
ion.=20
> I like the proposal, it's an interesting evolution.
>=20
> I just have a few questions to the authors:
>=20
> 1) kernel implementations are usually the opposite: they use no floating=
=20
> point by default, except in a few specific cases. Is the intention that e=
very=20
> function that doesn't use floating-point be marked? That seems like a rec=
ipe=20
> for mistake, as it would be easy to forget to mark a few functions. Would=
it=20
> be possible to provide a translation-unit-wide marker saying "none of the=
se=20
> functions require floating point=E2=80=9D?
See wg21.link/P1245R0 <http://wg21.link/P1245R0> for how we see this workin=
g. We also expect that particular targets would warn if the attribute isn=
=E2=80=99t present, or something like clang-tidy would be used.
> 2) if there's a TU-wide marker, should there be an inverse attribute=20
> "yes_float" (with a better name)?
Yes.
> 3) I'm also not sure the name "no_float" is the best. As you note in poin=
t #4=20
> of what it means to use such an attribute, an implementation-defined=20
> consequence is that vectorisation should be suppressed as those use the s=
ame=20
> registers as floating point. But that's not the case for all architecture=
s,=20
> x86 32-bit being the prime example. Therefore, "no_float" changing the co=
de=20
> generation for integral / byte-level operations could be surprising. Have=
you=20
> received any other suggestions for a name? Possibly splitting the behavio=
ur=20
> between FP and integral vector codegen changes?
We can bikeshed at will.
> It's especially surprising that one would mark [[no_float]] functions tha=
t=20
> already don't do floating point. It seems that kernel developers would be=
=20
> abusing the attribute for its implementation-specific side-effects, inste=
ad of=20
> the main purpose. And if one wants to deal with implementation-specific=
=20
> effects, why should that be in the standard?
>=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>=20
>=20
>=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/DAEA6AC1-67C4-4369-B5E0-DA977F635050%40apple.com=
..
--Boundary_(ID_xe56jvUn6xsKmdT+LQZBTQ)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><block=
quote type=3D"cite" class=3D""><div class=3D"">On Oct 14, 2018, at 10:28 PM=
, Thiago Macieira <<a href=3D"mailto:thiago@macieira.org" class=3D"">thi=
ago@macieira.org</a>> wrote:</div><br class=3D"Apple-interchange-newline=
"><div class=3D""><div class=3D"">Ref: <a href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2018/p1246r0.html" class=3D"">http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html</a><br class=3D""><br cla=
ss=3D"">The paper proposes a new function attribute to prevent the generati=
on of <br class=3D"">floating point instructions by the compiler, clearly m=
arking such a function. <br class=3D"">I like the proposal, it's an interes=
ting evolution.<br class=3D""><br class=3D"">I just have a few questions to=
the authors:<br class=3D""><br class=3D""> 1) kernel implementations are u=
sually the opposite: they use no floating <br class=3D"">point by default, =
except in a few specific cases. Is the intention that every <br class=3D"">=
function that doesn't use floating-point be marked? That seems like a recip=
e <br class=3D"">for mistake, as it would be easy to forget to mark a few f=
unctions. Would it <br class=3D"">be possible to provide a translation-unit=
-wide marker saying "none of these <br class=3D"">functions require floatin=
g point=E2=80=9D?<br class=3D""></div></div></blockquote><div><br class=3D"=
"></div><div>See <a href=3D"http://wg21.link/P1245R0" class=3D"">wg21.=
link/P1245R0</a> for how we see this working. We also expect that part=
icular targets would warn if the attribute isn=E2=80=99t present, or someth=
ing like clang-tidy would be used.</div><div><br class=3D""></div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div class=3D"">=
2) if there's a TU-wide marker, should there be an inverse attribute <br c=
lass=3D"">"yes_float" (with a better name)?<br class=3D""></div></div></blo=
ckquote><div><br class=3D""></div><div>Yes.</div><div><br class=3D""></div>=
<br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div cl=
ass=3D""> 3) I'm also not sure the name "no_float" is the best. As you note=
in point #4 <br class=3D"">of what it means to use such an attribute, an i=
mplementation-defined <br class=3D"">consequence is that vectorisation shou=
ld be suppressed as those use the same <br class=3D"">registers as floating=
point. But that's not the case for all architectures, <br class=3D"">x86 3=
2-bit being the prime example. Therefore, "no_float" changing the code <br =
class=3D"">generation for integral / byte-level operations could be surpris=
ing. Have you <br class=3D"">received any other suggestions for a name? Pos=
sibly splitting the behaviour <br class=3D"">between FP and integral vector=
codegen changes?<br class=3D""></div></div></blockquote><div><br class=3D"=
"></div><div>We can bikeshed at will.</div><div><br class=3D""></div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div class=3D=
"">It's especially surprising that one would mark [[no_float]] functions th=
at <br class=3D"">already don't do floating point. It seems that kernel dev=
elopers would be <br class=3D"">abusing the attribute for its implementatio=
n-specific side-effects, instead of <br class=3D"">the main purpose. And if=
one wants to deal with implementation-specific <br class=3D"">effects, why=
should that be in the standard?<br class=3D""><br class=3D"">-- <br class=
=3D"">Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" class=
=3D"">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" class=3D""=
>kde.org</a><br class=3D""> Software Architect - Intel Open Sou=
rce Technology Center<br class=3D""><br class=3D""><br class=3D""><br class=
=3D""></div></div></blockquote></div><br class=3D""></body></html>
<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/DAEA6AC1-67C4-4369-B5E0-DA977F635050%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/DAEA6AC1-67C4-4369-B5E0-DA977F635050%=
40apple.com</a>.<br />
--Boundary_(ID_xe56jvUn6xsKmdT+LQZBTQ)--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 15 Oct 2018 22:09:53 -0700 (PDT)
Raw View
------=_Part_1752_1655453063.1539666593707
Content-Type: multipart/alternative;
boundary="----=_Part_1753_312314556.1539666593707"
------=_Part_1753_312314556.1539666593707
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago Macieira wrote:
>
> Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html=
=20
>
> The paper proposes a new function attribute to prevent the generation of=
=20
> floating point instructions by the compiler, clearly marking such a=20
> function.=20
My take on this proposal is that it's a not-quite-well-motivated attempt to=
=20
come up with a concrete use case for P1245=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1245r0.html>'s=20
"module-level attributes."
P1245 is proposing a core grammar change to allow [[attribute]]s on module=
=20
exports (and imports?). This seems fine and noble.
P1246 is proposing a specific *novel* attribute with no prior art,=20
primarily so that there will be something in the standard that uses the=20
P1245 grammar production. This seems unnecessary and ill-advised. If=20
there's any actual demand for [[no_float]], why not implement it as e.g.=20
[[clang::no_float]] and try to get it shipped by a compiler vendor first?=
=20
*Then* present it to WG21 under the rubric of standardizing existing=20
practice.
All of Thiago's questions seem like things that would fall naturally out of=
=20
any attempt at a compiler implementation. Do the implementation first;=20
that'll guide the syntax and semantics. I hope EWG doesn't spend any=20
precious San Diego time discussing P1246 in its current state. (But P1245,=
=20
as I said, seems like a fine idea.)
my $.02,
=E2=80=93Arthur
--=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/77c03c2b-e566-4315-9ed4-b2de8d61c6b0%40isocpp.or=
g.
------=_Part_1753_312314556.1539666593707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Ref: <a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.go=
ogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs=
%2Fpapers%2F2018%2Fp1246r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXr=
NmlosyVsuAEeMjPWjEme2rcMw';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2018%2Fp1246r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHXrNmlosyVsuAEeMjPWjEme2rcMw';return true;">http://www.open-std=
..org/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wbr>p1246r0.html</a>
<br>
<br>The paper proposes a new function attribute to prevent the generation o=
f=20
<br>floating point instructions by the compiler, clearly marking such a fun=
ction. </blockquote><div><br></div><div>My take on this proposal is that it=
's a not-quite-well-motivated attempt to come up with a concrete use ca=
se for <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p=
1245r0.html">P1245</a>'s "module-level attributes."</div><div=
>P1245 is proposing a core grammar change to allow [[attribute]]s on module=
exports (and imports?). =C2=A0This seems fine and noble.</div><div>P1246 i=
s proposing a specific <i><b>novel</b></i> attribute with no prior art, pri=
marily so that there will be something in the standard that uses the P1245 =
grammar production. =C2=A0This seems unnecessary and ill-advised. If there&=
#39;s any actual demand for [[no_float]], why not implement it as e.g. [[cl=
ang::no_float]] and try to get it shipped by a compiler vendor first? <i>Th=
en</i> present it to WG21 under the rubric of standardizing existing practi=
ce.</div><div><br></div><div>All of Thiago's questions seem like things=
that would fall naturally out of any attempt at a compiler implementation.=
Do the implementation first; that'll guide the syntax and semantics. =
=C2=A0I hope EWG doesn't spend any precious San Diego time discussing P=
1246 in its current state. =C2=A0(But P1245, as I said, seems like a fine i=
dea.)</div><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div></di=
v>
<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/77c03c2b-e566-4315-9ed4-b2de8d61c6b0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77c03c2b-e566-4315-9ed4-b2de8d61c6b0=
%40isocpp.org</a>.<br />
------=_Part_1753_312314556.1539666593707--
------=_Part_1752_1655453063.1539666593707--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Mon, 15 Oct 2018 22:18:27 -0700
Raw View
--Boundary_(ID_Hv+VljQUYFobUjdZnoYlQA)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Oct 15, 2018, at 10:09 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> =
wrote:
>=20
> On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago Macieira wrote:
> Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html=
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html>=20
>=20
> The paper proposes a new function attribute to prevent the generation of=
=20
> floating point instructions by the compiler, clearly marking such a funct=
ion.
>=20
> My take on this proposal is that it's a not-quite-well-motivated attempt =
to come up with a concrete use case for P1245 <http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2018/p1245r0.html>'s "module-level attributes."
> P1245 is proposing a core grammar change to allow [[attribute]]s on modul=
e exports (and imports?). This seems fine and noble.
> P1246 is proposing a specific novel attribute with no prior art, primaril=
y so that there will be something in the standard that uses the P1245 gramm=
ar production. This seems unnecessary and ill-advised. If there's any actu=
al demand for [[no_float]], why not implement it as e.g. [[clang::no_float]=
] and try to get it shipped by a compiler vendor first? Then present it to =
WG21 under the rubric of standardizing existing practice.
>=20
> All of Thiago's questions seem like things that would fall naturally out =
of any attempt at a compiler implementation. Do the implementation first; t=
hat'll guide the syntax and semantics. I hope EWG doesn't spend any precio=
us San Diego time discussing P1246 in its current state. (But P1245, as I =
said, seems like a fine idea.)
We=E2=80=99ll implement it, worry not. Just haven=E2=80=99t gotten around t=
o it. We have concrete motivation for it, and again today I wish we had the=
attribute.
Don=E2=80=99t worry, EWG won=E2=80=99t spend time on this paper in San Dieg=
o :-)
In fact, this paper will be a role model in how it=E2=80=99s treated in San=
Diego!
--=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/14F03BD0-31EF-423B-853F-26BF8839752C%40apple.com=
..
--Boundary_(ID_Hv+VljQUYFobUjdZnoYlQA)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Oct 15, 20=
18, at 10:09 PM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail=
..com" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On =
Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago Macieira wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Ref: <a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html" target=3D"_blank" rel=3D"=
nofollow" class=3D"">http://www.open-std.org/jtc1/<wbr class=3D"">sc22/wg21=
/docs/papers/2018/<wbr class=3D"">p1246r0.html</a>
<br class=3D"">
<br class=3D"">The paper proposes a new function attribute to prevent the g=
eneration of=20
<br class=3D"">floating point instructions by the compiler, clearly marking=
such a function. </blockquote><div class=3D""><br class=3D""></div><div cl=
ass=3D"">My take on this proposal is that it's a not-quite-well-motivated a=
ttempt to come up with a concrete use case for <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2018/p1245r0.html" class=3D"">P1245</a>'s=
"module-level attributes."</div><div class=3D"">P1245 is proposing a core =
grammar change to allow [[attribute]]s on module exports (and imports?). &n=
bsp;This seems fine and noble.</div><div class=3D"">P1246 is proposing a sp=
ecific <i class=3D""><b class=3D"">novel</b></i> attribute with no prior ar=
t, primarily so that there will be something in the standard that uses the =
P1245 grammar production. This seems unnecessary and ill-advised. If =
there's any actual demand for [[no_float]], why not implement it as e.g. [[=
clang::no_float]] and try to get it shipped by a compiler vendor first? <i =
class=3D"">Then</i> present it to WG21 under the rubric of standardizing ex=
isting practice.</div><div class=3D""><br class=3D""></div><div class=3D"">=
All of Thiago's questions seem like things that would fall naturally out of=
any attempt at a compiler implementation. Do the implementation first; tha=
t'll guide the syntax and semantics. I hope EWG doesn't spend any pre=
cious San Diego time discussing P1246 in its current state. (But P124=
5, as I said, seems like a fine idea.)</div></div></div></blockquote><br cl=
ass=3D""></div><div>We=E2=80=99ll implement it, worry not. Just haven=E2=80=
=99t gotten around to it. We have concrete motivation for it, and again tod=
ay I wish we had the attribute.</div><div><br class=3D""></div><div>Don=E2=
=80=99t worry, EWG won=E2=80=99t spend time on this paper in San Diego :-)<=
/div>In fact, this paper will be a role model in how it=E2=80=99s treated i=
n San Diego!<div class=3D""><br class=3D""></div></body></html>
<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/14F03BD0-31EF-423B-853F-26BF8839752C%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/14F03BD0-31EF-423B-853F-26BF8839752C%=
40apple.com</a>.<br />
--Boundary_(ID_Hv+VljQUYFobUjdZnoYlQA)--
.
Author: "Ivan G." <nekotekina@gmail.com>
Date: Tue, 16 Oct 2018 02:34:15 -0700 (PDT)
Raw View
------=_Part_1982_1942925223.1539682455908
Content-Type: multipart/alternative;
boundary="----=_Part_1983_48662061.1539682455908"
------=_Part_1983_48662061.1539682455908
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
It seems the primary motivation for this attribute is having a calling=20
convention which guarantees that SIMD registers will not be modified.
But SIMD registers usually work not only with floating point values, but=20
with packed integral values as well, which raises many questions.
I think the attribute should be named [[gpr_only]], meaning that the=20
function uses only general-purpose registers.
This can be meaningful for many architectures, not only x86.
I believe that a [[gpr_only]] function still can use floating-point=20
arguments and results. They just shouldn't use special registers for this -=
=20
I see no problem in passing floating point values on stack or=20
general-purpose registers, since the calling convention is altered anyway.=
=20
Simply copying FP values doesn't necessarily require modifying xmm/x87/etc=
=20
registers.
Maybe even doing the computation involving them is still possible, if the=
=20
extended state is preserved. Just save all the modified non-general-purpose=
=20
registers and restore them. Although it seems hard to arbitrarily save AVX=
=20
state on x86.
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2018 =D0=B3., 8:18:33 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C JF Bastien =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB:
>
>
>
> On Oct 15, 2018, at 10:09 PM, Arthur O'Dwyer <arthur....@gmail.com=20
> <javascript:>> wrote:
>
> On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago Macieira wrote:
>>
>> Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.htm=
l=20
>>
>> The paper proposes a new function attribute to prevent the generation of=
=20
>> floating point instructions by the compiler, clearly marking such a=20
>> function.=20
>
>
> My take on this proposal is that it's a not-quite-well-motivated attempt=
=20
> to come up with a concrete use case for P1245=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1245r0.html>'s=
=20
> "module-level attributes."
> P1245 is proposing a core grammar change to allow [[attribute]]s on modul=
e=20
> exports (and imports?). This seems fine and noble.
> P1246 is proposing a specific *novel* attribute with no prior art,=20
> primarily so that there will be something in the standard that uses the=
=20
> P1245 grammar production. This seems unnecessary and ill-advised. If=20
> there's any actual demand for [[no_float]], why not implement it as e.g.=
=20
> [[clang::no_float]] and try to get it shipped by a compiler vendor first?=
=20
> *Then* present it to WG21 under the rubric of standardizing existing=20
> practice.
>
> All of Thiago's questions seem like things that would fall naturally out=
=20
> of any attempt at a compiler implementation. Do the implementation first;=
=20
> that'll guide the syntax and semantics. I hope EWG doesn't spend any=20
> precious San Diego time discussing P1246 in its current state. (But P124=
5,=20
> as I said, seems like a fine idea.)
>
>
> We=E2=80=99ll implement it, worry not. Just haven=E2=80=99t gotten around=
to it. We have=20
> concrete motivation for it, and again today I wish we had the attribute.
>
> Don=E2=80=99t worry, EWG won=E2=80=99t spend time on this paper in San Di=
ego :-)
> In fact, this paper will be a role model in how it=E2=80=99s treated in S=
an Diego!
>
>
--=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/f6b2fba3-45db-4d29-9e8c-4c0b55bace78%40isocpp.or=
g.
------=_Part_1983_48662061.1539682455908
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It seems the primary motivation for this attribute is havi=
ng a calling convention which guarantees that SIMD registers will not be mo=
dified.<div><br></div><div>But SIMD registers usually work not only with fl=
oating point values, but with packed integral values as well, which raises =
many questions.<br></div><div><br></div><div>I think the attribute should b=
e named [[gpr_only]], meaning that the function uses only general-purpose r=
egisters.</div><div><br></div><div>This can be meaningful for many architec=
tures, not only x86.</div><div><br></div><div>I believe that a [[gpr_only]]=
function still can use floating-point arguments and results. They just sho=
uldn't use special registers for this - I see no problem in passing flo=
ating point values on stack or general-purpose registers, since the calling=
convention is altered anyway. Simply copying FP values doesn't necessa=
rily require modifying xmm/x87/etc registers.</div><div><br></div><div>Mayb=
e even doing the computation involving them is still possible, if the exten=
ded state is preserved. Just save all the modified non-general-purpose regi=
sters and restore them. Although it seems hard to arbitrarily save AVX stat=
e on x86.</div>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=
=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2018 =D0=B3., 8:18:33 UTC+3 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C JF Bastien =D0=BD=
=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div style=3D"word-wrap:break-word;line-break:after-white-space"><br=
><div><br><blockquote type=3D"cite"><div>On Oct 15, 2018, at 10:09 PM, Arth=
ur O'Dwyer <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"RmnjKjuLBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">arthur....@gmail.com</a>> wrote:</div><br><div><div dir=3D=
"ltr">On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago Macieira wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Ref: <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html" rel=3D"nofollow" targ=
et=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018=
%2Fp1246r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXrNmlosyVsuAEeMjPW=
jEme2rcMw';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2018%2Fp1246r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHXrNmlos=
yVsuAEeMjPWjEme2rcMw';return true;">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2018/p1246r0.html</a>
<br>
<br>The paper proposes a new function attribute to prevent the generation o=
f=20
<br>floating point instructions by the compiler, clearly marking such a fun=
ction. </blockquote><div><br></div><div>My take on this proposal is that it=
's a not-quite-well-motivated attempt to come up with a concrete use ca=
se for <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p=
1245r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1245r0.html\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNGG7pgRQGMMstlpXfugU7RDv-SxSw';return true;" onclick=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1245r0.html\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNGG7pgRQGMMstlpXfugU7RDv-SxSw';return true;">P=
1245</a>'s "module-level attributes."</div><div>P1245 is prop=
osing a core grammar change to allow [[attribute]]s on module exports (and =
imports?). =C2=A0This seems fine and noble.</div><div>P1246 is proposing a =
specific <i><b>novel</b></i> attribute with no prior art, primarily so that=
there will be something in the standard that uses the P1245 grammar produc=
tion. =C2=A0This seems unnecessary and ill-advised. If there's any actu=
al demand for [[no_float]], why not implement it as e.g. [[clang::no_float]=
] and try to get it shipped by a compiler vendor first? <i>Then</i> present=
it to WG21 under the rubric of standardizing existing practice.</div><div>=
<br></div><div>All of Thiago's questions seem like things that would fa=
ll naturally out of any attempt at a compiler implementation. Do the implem=
entation first; that'll guide the syntax and semantics. =C2=A0I hope EW=
G doesn't spend any precious San Diego time discussing P1246 in its cur=
rent state. =C2=A0(But P1245, as I said, seems like a fine idea.)</div></di=
v></div></blockquote><br></div><div>We=E2=80=99ll implement it, worry not. =
Just haven=E2=80=99t gotten around to it. We have concrete motivation for i=
t, and again today I wish we had the attribute.</div><div><br></div><div>Do=
n=E2=80=99t worry, EWG won=E2=80=99t spend time on this paper in San Diego =
:-)</div>In fact, this paper will be a role model in how it=E2=80=99s treat=
ed in San Diego!<div><br></div></div></blockquote></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/f6b2fba3-45db-4d29-9e8c-4c0b55bace78%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6b2fba3-45db-4d29-9e8c-4c0b55bace78=
%40isocpp.org</a>.<br />
------=_Part_1983_48662061.1539682455908--
------=_Part_1982_1942925223.1539682455908--
.
Author: pasa@lib.hu
Date: Tue, 16 Oct 2018 08:32:54 -0700 (PDT)
Raw View
------=_Part_2169_1810335206.1539703974387
Content-Type: multipart/alternative;
boundary="----=_Part_2170_642005901.1539703974387"
------=_Part_2170_642005901.1539703974387
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
To me the whole proposal looks very niche. But the main point I don't get=
=20
is:
>3. Other functions that use floating-point types can be called from one=20
marked with the no_float attribute as long as the callee=E2=80=99s paramete=
rs and=20
return type aren=E2=80=99t floating-point.
With that how and what is helped? The rest suggests wanting to make the=20
body free from touching any FP and leave the state at found. If the body=
=20
has no such instructions itself but calls another function that gets=20
inlined there, I have the instructions in the body. And if not inlined,=
=20
still no difference as the FP state can be altered. If it can not, without=
=20
the attribute, then what is the point of the attribute?
To make sense (IMHO) this point should state that such function can only=20
call functions wearing the same attribute. (and specified that way I expect=
=20
some fallout in expected usability).
--=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/b1264874-93cf-426a-96e5-e9e157a5cb3e%40isocpp.or=
g.
------=_Part_2170_642005901.1539703974387
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To me the whole proposal looks very niche. But the main po=
int I don't get is:<br><br>>3. Other functions that use floating-poi=
nt types can be called from one marked with the no_float attribute as long =
as the callee=E2=80=99s parameters and return type aren=E2=80=99t floating-=
point.<br><br>With that how and what is helped? The rest suggests wanting t=
o make the body free from touching any FP and leave the state at found.=C2=
=A0 If the body has no such instructions itself but calls another function =
that gets inlined there, I have the instructions in the body.=C2=A0=C2=A0 A=
nd if not inlined, still no difference as the FP state can be altered. If i=
t can not, without the attribute, then what is the point of the attribute?<=
br><br>To make sense (IMHO) this point should state that such function can =
only call functions wearing the same attribute. (and specified that way I e=
xpect some fallout in expected usability).<br><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/b1264874-93cf-426a-96e5-e9e157a5cb3e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b1264874-93cf-426a-96e5-e9e157a5cb3e=
%40isocpp.org</a>.<br />
------=_Part_2170_642005901.1539703974387--
------=_Part_2169_1810335206.1539703974387--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Tue, 16 Oct 2018 08:51:50 -0700
Raw View
> On Oct 16, 2018, at 8:32 AM, pasa@lib.hu wrote:
>=20
> To me the whole proposal looks very niche. But the main point I don't get=
is:
>=20
> >3. Other functions that use floating-point types can be called from one =
marked with the no_float attribute as long as the callee=E2=80=99s paramete=
rs and return type aren=E2=80=99t floating-point.
>=20
> With that how and what is helped? The rest suggests wanting to make the b=
ody free from touching any FP and leave the state at found. If the body ha=
s no such instructions itself but calls another function that gets inlined =
there, I have the instructions in the body. And if not inlined, still no =
difference as the FP state can be altered. If it can not, without the attri=
bute, then what is the point of the attribute?
You can=E2=80=99t inline functions with incompatible attributes, or if you =
do you have to preserve those attributes in some other manner.
> To make sense (IMHO) this point should state that such function can only =
call functions wearing the same attribute. (and specified that way I expect=
some fallout in expected usability).
>=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56103F24-5C47-4874-9CFB-A7771EF5999C%40apple.com=
..
.
Author: JF Bastien <jfbastien@apple.com>
Date: Tue, 16 Oct 2018 08:55:36 -0700
Raw View
--Boundary_(ID_cK346rY5ekvTtsFcZlDWPQ)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Oct 16, 2018, at 2:34 AM, Ivan G. <nekotekina@gmail.com> wrote:
>=20
> It seems the primary motivation for this attribute is having a calling co=
nvention which guarantees that SIMD registers will not be modified.
More than just calling convention.
> But SIMD registers usually work not only with floating point values, but =
with packed integral values as well, which raises many questions.
Indeed we want to forbid these registers from being used, implicitly or exp=
licitly. Doesn=E2=80=99t matter if it=E2=80=99s FP or integers.
> I think the attribute should be named [[gpr_only]], meaning that the func=
tion uses only general-purpose registers.
We can bikeshed in EWG (or other venue which sees the paper).
> This can be meaningful for many architectures, not only x86.
Yes.
> I believe that a [[gpr_only]] function still can use floating-point argum=
ents and results. They just shouldn't use special registers for this - I se=
e no problem in passing floating point values on stack or general-purpose r=
egisters, since the calling convention is altered anyway. Simply copying FP=
values doesn't necessarily require modifying xmm/x87/etc registers.
It would require soft-float for any modification, which we want to avoid. F=
or sure you can pass the values around using GPRs.
> Maybe even doing the computation involving them is still possible, if the=
extended state is preserved. Just save all the modified non-general-purpos=
e registers and restore them. Although it seems hard to arbitrarily save AV=
X state on x86.
That=E2=80=99s not acceptable in the use cases we=E2=80=99re trying to meet=
..
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=
=D0=B1=D1=80=D1=8F 2018 =D0=B3., 8:18:33 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C JF Bastien =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0=D0=BB:
>=20
>=20
>> On Oct 15, 2018, at 10:09 PM, Arthur O'Dwyer <arthur....@gmail.com <>> w=
rote:
>>=20
>> On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Thiago Macieira wrote:
>> Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.htm=
l <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html>=20
>>=20
>> The paper proposes a new function attribute to prevent the generation of=
=20
>> floating point instructions by the compiler, clearly marking such a func=
tion.
>>=20
>> My take on this proposal is that it's a not-quite-well-motivated attempt=
to come up with a concrete use case for P1245 <http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2018/p1245r0.html>'s "module-level attributes."
>> P1245 is proposing a core grammar change to allow [[attribute]]s on modu=
le exports (and imports?). This seems fine and noble.
>> P1246 is proposing a specific novel attribute with no prior art, primari=
ly so that there will be something in the standard that uses the P1245 gram=
mar production. This seems unnecessary and ill-advised. If there's any act=
ual demand for [[no_float]], why not implement it as e.g. [[clang::no_float=
]] and try to get it shipped by a compiler vendor first? Then present it to=
WG21 under the rubric of standardizing existing practice.
>>=20
>> All of Thiago's questions seem like things that would fall naturally out=
of any attempt at a compiler implementation. Do the implementation first; =
that'll guide the syntax and semantics. I hope EWG doesn't spend any preci=
ous San Diego time discussing P1246 in its current state. (But P1245, as I=
said, seems like a fine idea.)
>=20
> We=E2=80=99ll implement it, worry not. Just haven=E2=80=99t gotten around=
to it. We have concrete motivation for it, and again today I wish we had t=
he attribute.
>=20
> Don=E2=80=99t worry, EWG won=E2=80=99t spend time on this paper in San Di=
ego :-)
> In fact, this paper will be a role model in how it=E2=80=99s treated in S=
an Diego!
>=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/D9BE0E7A-1BB0-4A5E-80E9-06A262C772D4%40apple.com=
..
--Boundary_(ID_cK346rY5ekvTtsFcZlDWPQ)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Oct 16, 20=
18, at 2:34 AM, Ivan G. <<a href=3D"mailto:nekotekina@gmail.com" class=
=3D"">nekotekina@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><div class=3D""><div dir=3D"ltr" class=3D"">It seems the primar=
y motivation for this attribute is having a calling convention which guaran=
tees that SIMD registers will not be modified.</div></div></blockquote><div=
><br class=3D""></div><div>More than just calling convention.</div><div><br=
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">But SIMD registers u=
sually work not only with floating point values, but with packed integral v=
alues as well, which raises many questions.</div></div></div></blockquote><=
div><br class=3D""></div><div>Indeed we want to forbid these registers from=
being used, implicitly or explicitly. Doesn=E2=80=99t matter if it=E2=80=
=99s FP or integers.</div><div><br class=3D""></div><br class=3D""><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><d=
iv class=3D"">I think the attribute should be named [[gpr_only]], meaning t=
hat the function uses only general-purpose registers.</div></div></div></bl=
ockquote><div><br class=3D""></div><div>We can bikeshed in EWG (or other ve=
nue which sees the paper).</div><div><br class=3D""></div><br class=3D""><b=
lockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"">This can be meaningful for many architectures, not on=
ly x86.</div></div></div></blockquote><div><br class=3D""></div><div>Yes.</=
div><div><br class=3D""></div><br class=3D""><blockquote type=3D"cite" clas=
s=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">I believ=
e that a [[gpr_only]] function still can use floating-point arguments and r=
esults. They just shouldn't use special registers for this - I see no probl=
em in passing floating point values on stack or general-purpose registers, =
since the calling convention is altered anyway. Simply copying FP values do=
esn't necessarily require modifying xmm/x87/etc registers.</div></div></div=
></blockquote><div><br class=3D""></div><div>It would require soft-float fo=
r any modification, which we want to avoid. For sure you can pass the value=
s around using GPRs.</div><div><br class=3D""></div><br class=3D""><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><d=
iv class=3D"">Maybe even doing the computation involving them is still poss=
ible, if the extended state is preserved. Just save all the modified non-ge=
neral-purpose registers and restore them. Although it seems hard to arbitra=
rily save AVX state on x86.</div></div></div></blockquote><div><br class=3D=
""></div><div>That=E2=80=99s not acceptable in the use cases we=E2=80=99re =
trying to meet.</div><div><br class=3D""></div><br class=3D""><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">=D0=B2=
=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=
=80=D1=8F 2018 =D0=B3., 8:18:33 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=
=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C JF Bastien =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word;line-break:after-white-space" class=3D""><br class=3D"=
"><div class=3D""><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Oct 15, 2018, at 10:09 PM, Arthur O'Dwyer <<a target=3D"_b=
lank" gdf-obfuscated-mailto=3D"RmnjKjuLBAAJ" rel=3D"nofollow" class=3D"">ar=
thur....@gmail.com</a>> wrote:</div><br class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D"">On Sunday, October 14, 2018 at 10:28:48 PM UTC-7, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Ref: <a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1246r0.html" rel=
=3D"nofollow" target=3D"_blank" class=3D"">http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2018/p1246r0.html</a>
<br class=3D"">
<br class=3D"">The paper proposes a new function attribute to prevent the g=
eneration of=20
<br class=3D"">floating point instructions by the compiler, clearly marking=
such a function. </blockquote><div class=3D""><br class=3D""></div><div cl=
ass=3D"">My take on this proposal is that it's a not-quite-well-motivated a=
ttempt to come up with a concrete use case for <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2018/p1245r0.html" target=3D"_blank" rel=
=3D"nofollow" class=3D"">P1245</a>'s "module-level attributes."</div><div c=
lass=3D"">P1245 is proposing a core grammar change to allow [[attribute]]s =
on module exports (and imports?). This seems fine and noble.</div><di=
v class=3D"">P1246 is proposing a specific <i class=3D""><b class=3D"">nove=
l</b></i> attribute with no prior art, primarily so that there will be some=
thing in the standard that uses the P1245 grammar production. This se=
ems unnecessary and ill-advised. If there's any actual demand for [[no_floa=
t]], why not implement it as e.g. [[clang::no_float]] and try to get it shi=
pped by a compiler vendor first? <i class=3D"">Then</i> present it to WG21 =
under the rubric of standardizing existing practice.</div><div class=3D""><=
br class=3D""></div><div class=3D"">All of Thiago's questions seem like thi=
ngs that would fall naturally out of any attempt at a compiler implementati=
on. Do the implementation first; that'll guide the syntax and semantics. &n=
bsp;I hope EWG doesn't spend any precious San Diego time discussing P1246 i=
n its current state. (But P1245, as I said, seems like a fine idea.)<=
/div></div></div></blockquote><br class=3D""></div><div class=3D"">We=E2=80=
=99ll implement it, worry not. Just haven=E2=80=99t gotten around to it. We=
have concrete motivation for it, and again today I wish we had the attribu=
te.</div><div class=3D""><br class=3D""></div><div class=3D"">Don=E2=80=99t=
worry, EWG won=E2=80=99t spend time on this paper in San Diego :-)</div>In=
fact, this paper will be a role model in how it=E2=80=99s treated in San D=
iego!<div class=3D""><br class=3D""></div></div></blockquote></div></div></=
blockquote></div><br class=3D""></body></html>
<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/D9BE0E7A-1BB0-4A5E-80E9-06A262C772D4%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/D9BE0E7A-1BB0-4A5E-80E9-06A262C772D4%=
40apple.com</a>.<br />
--Boundary_(ID_cK346rY5ekvTtsFcZlDWPQ)--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 16 Oct 2018 11:30:41 -0700
Raw View
On Tuesday, 16 October 2018 08:55:36 PDT JF Bastien wrote:
> > I believe that a [[gpr_only]] function still can use floating-point
> > arguments and results. They just shouldn't use special registers for this
> > - I see no problem in passing floating point values on stack or
> > general-purpose registers, since the calling convention is altered
> > anyway. Simply copying FP values doesn't necessarily require modifying
> > xmm/x87/etc registers.
> It would require soft-float for any modification, which we want to avoid.
> For sure you can pass the values around using GPRs.
I agree here, there's no need to invent an alternate calling convention. If
someone wants to pass the bit contents of a double via soft-float to a target
function, copy it to a suitably-sized buffer or suitably-sized integer. The
receiver will do what it needs to 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/2184749.jXekUV8D07%40tjmaciei-mobl1.
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 16 Oct 2018 13:06:25 -0700 (PDT)
Raw View
------=_Part_2440_1140020668.1539720385513
Content-Type: multipart/alternative;
boundary="----=_Part_2441_1623748471.1539720385513"
------=_Part_2441_1623748471.1539720385513
Content-Type: text/plain; charset="UTF-8"
On Monday, October 15, 2018 at 10:09:53 PM UTC-7, Arthur O'Dwyer wrote:
>
> My take on this proposal is that it's a not-quite-well-motivated attempt
> to come up with a concrete use case for P1245
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1245r0.html>'s
> "module-level attributes."
> P1245 is proposing a core grammar change to allow [[attribute]]s on module
> exports (and imports?). This seems fine and noble.
> P1246 is proposing a specific *novel* attribute with no prior art,
> primarily so that there will be something in the standard that uses the
> P1245 grammar production. This seems unnecessary and ill-advised. If
> there's any actual demand for [[no_float]], why not implement it as e.g.
> [[clang::no_float]] and try to get it shipped by a compiler vendor first?
> *Then* present it to WG21 under the rubric of standardizing existing
> practice.
>
>
Something like no_float is going to be extremely implementation-specific as
to its meaning. A given environment could very well have multiple types of
restrictions, not just no_float. There are things in GCC for similar
problems, such as __attribute__((__interrupt__)) in some environments to
tell the compiler to make an interrupt handler stack frame instead of a
normal stack frame.
In Windows NT kernel drivers, on x86-32, you can't use x87 or SSE
instructions in the kernel unless you follow certain rules (calling
KeSaveExtendedProcessorState, etc.). On x86-64, you can use SSE normally,
including floating-point math, but restrictions apply to AVX.
It doesn't make sense to me to add this as a generic feature to the
Standard, when its meaning will vary widely. This needs to be handled as
compiler-specific attributes and/or command-line parameters, in my opinion.
--
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/a781b732-48fb-4a65-bbeb-51331c6b4d41%40isocpp.org.
------=_Part_2441_1623748471.1539720385513
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 15, 2018 at 10:09:53 PM UTC-7, Arthur O=
'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">My take on this proposal is that it's a not-quite-well-motivated at=
tempt to come up with a concrete use case for <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2018/p1245r0.html" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018=
%2Fp1245r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGG7pgRQGMMstlpXfugU=
7RDv-SxSw';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2018%2Fp1245r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGG7pgRQG=
MMstlpXfugU7RDv-SxSw';return true;">P1245</a>'s "module-level =
attributes."<div>P1245 is proposing a core grammar change to allow [[a=
ttribute]]s on module exports (and imports?). =C2=A0This seems fine and nob=
le.</div><div>P1246 is proposing a specific <i><b>novel</b></i> attribute w=
ith no prior art, primarily so that there will be something in the standard=
that uses the P1245 grammar production. =C2=A0This seems unnecessary and i=
ll-advised. If there's any actual demand for [[no_float]], why not impl=
ement it as e.g. [[clang::no_float]] and try to get it shipped by a compile=
r vendor first? <i>Then</i> present it to WG21 under the rubric of standard=
izing existing practice.</div><br></div></blockquote><div><br></div><div>So=
mething like no_float is going to be extremely implementation-specific as t=
o its meaning.=C2=A0 A given environment could very well have multiple type=
s of restrictions, not just no_float.=C2=A0 There are things in GCC for sim=
ilar problems, such as __attribute__((__interrupt__)) in some environments =
to tell the compiler to make an interrupt handler stack frame instead of a =
normal stack frame.</div><div><br></div><div>In Windows NT kernel drivers, =
on x86-32, you can't use x87 or SSE instructions in the kernel unless y=
ou follow certain rules (calling KeSaveExtendedProcessorState, etc.).=C2=A0=
On x86-64, you can use SSE normally, including floating-point math, but re=
strictions apply to AVX.<br></div><div><br></div><div>It doesn't make s=
ense to me to add this as a generic feature to the Standard, when its meani=
ng will vary widely.=C2=A0 This needs to be handled as compiler-specific at=
tributes and/or command-line parameters, in my opinion.<br></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/a781b732-48fb-4a65-bbeb-51331c6b4d41%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a781b732-48fb-4a65-bbeb-51331c6b4d41=
%40isocpp.org</a>.<br />
------=_Part_2441_1623748471.1539720385513--
------=_Part_2440_1140020668.1539720385513--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Tue, 16 Oct 2018 18:22:34 -0700 (PDT)
Raw View
------=_Part_2321_1426148489.1539739355128
Content-Type: multipart/alternative;
boundary="----=_Part_2322_1408208783.1539739355129"
------=_Part_2322_1408208783.1539739355129
Content-Type: text/plain; charset="UTF-8"
How should vector, array, and other templates be annotated? Depending on
the type of T, they may be no_float or not.
In what way do you see this improving the developer experience? Could you
get the same benefit by dumping the disassembly of your binaries, and
searching for offending registers and instructions? On x64, the strings
"xmm", "ymm", and "zmm" don't show up too often, and developers could white
list the code where they have been super careful and used the FPU and
vector registers appropriately. I suspect the same could be done on arm,
just searching for the D# and Q# registers instead.
My concern with this annotation approach is that it assumes that most
module / function authors will annotate their code. I don't think people
will annotate their code if the code works in most hosted environments
without the annotation though. This ends up burdening the kernel /
embedded user with auditing the code (which they have to do today), then
updating the code to include the annotation (they don't need to do this
today). So it ends in more work an awful lot of the time. Maybe I'm being
pessimistic though, and there will be a rich set of libraries correctly
annotated with no_float.
--
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/75b941be-22dd-4032-b7c4-3fa717cc4453%40isocpp.org.
------=_Part_2322_1408208783.1539739355129
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How should vector, array, and other templates be annotated=
?=C2=A0 Depending on the type of T, they may be no_float or not.<div><br></=
div><div><br></div><div>In what way do you see this improving the developer=
experience?=C2=A0 Could you get the same benefit by dumping the disassembl=
y of your binaries, and searching for offending registers and instructions?=
=C2=A0 On x64, the strings "xmm", "ymm", and "zmm&=
quot; don't show up too often, and developers could white list the code=
where they have been super careful and used the FPU and vector registers a=
ppropriately.=C2=A0 I suspect the same could be done on arm, just searching=
for the D# and Q# registers instead.</div><div><br></div><div>My concern w=
ith this annotation approach is that it assumes that most module / function=
authors will annotate their code.=C2=A0 I don't think people will anno=
tate their code if the code works in most hosted environments without the a=
nnotation though.=C2=A0 This ends up burdening the kernel / embedded user w=
ith auditing the code (which they have to do today), then updating the code=
to include the annotation (they don't need to do this today).=C2=A0 So=
it ends in more work an awful lot of the time.=C2=A0 Maybe I'm being p=
essimistic though, and there will be a rich set of libraries correctly anno=
tated with no_float.</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/75b941be-22dd-4032-b7c4-3fa717cc4453%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/75b941be-22dd-4032-b7c4-3fa717cc4453=
%40isocpp.org</a>.<br />
------=_Part_2322_1408208783.1539739355129--
------=_Part_2321_1426148489.1539739355128--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 16 Oct 2018 18:38:21 -0700
Raw View
On Tuesday, 16 October 2018 18:22:34 PDT Ben Craig wrote:
> How should vector, array, and other templates be annotated? Depending on
> the type of T, they may be no_float or not.
Before answering how, please explain why they should be annotated in the first
place. What is the objective?
> In what way do you see this improving the developer experience? Could you
> get the same benefit by dumping the disassembly of your binaries, and
> searching for offending registers and instructions? On x64, the strings
> "xmm", "ymm", and "zmm" don't show up too often, and developers could white
> list the code where they have been super careful and used the FPU and
> vector registers appropriately. I suspect the same could be done on arm,
> just searching for the D# and Q# registers instead.
That is not a good solution, leading to long-term code maintainability. A
single change in a header you don't control can cause a previously unused
optimisation to kick in or a previously used one to be dumped, changing the
code generation and with it which registers get used. Not to mention of course
that compilers improve too. You can't count on the code not using some
instruction once as a guarantee it will never.
> My concern with this annotation approach is that it assumes that most
> module / function authors will annotate their code. I don't think people
> will annotate their code if the code works in most hosted environments
> without the annotation though. This ends up burdening the kernel /
> embedded user with auditing the code (which they have to do today), then
> updating the code to include the annotation (they don't need to do this
> today). So it ends in more work an awful lot of the time. Maybe I'm being
> pessimistic though, and there will be a rich set of libraries correctly
> annotated with no_float.
That was one of my points. It's much preferable for kernel developers to turn
the use of SSE explicitly off and explicitly turn on only where allowed.
--
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/10927078.UMMqV53PLs%40tjmaciei-mobl1.
.
Author: JF Bastien <jfbastien@apple.com>
Date: Tue, 16 Oct 2018 18:47:34 -0700
Raw View
> On Oct 16, 2018, at 6:22 PM, Ben Craig <ben.craig@gmail.com> wrote:
>=20
> How should vector, array, and other templates be annotated? Depending on=
the type of T, they may be no_float or not.
Don=E2=80=99t annotate them. The type of code this is useful for is often p=
retty much C code, with very few such dependencies.
> In what way do you see this improving the developer experience? Could yo=
u get the same benefit by dumping the disassembly of your binaries, and sea=
rching for offending registers and instructions?
From experience, this isn=E2=80=99t done. It=E2=80=99s also way better to h=
ave the compiler tell you that you messed up than have some random tool do =
so. The attribute document expectations for this function. This is traditio=
nally enforced with a comment, and comments have very little bearing with r=
eality.
> On x64, the strings "xmm", "ymm", and "zmm" don't show up too often, and =
developers could white list the code where they have been super careful and=
used the FPU and vector registers appropriately. I suspect the same could=
be done on arm, just searching for the D# and Q# registers instead.
>=20
> My concern with this annotation approach is that it assumes that most mod=
ule / function authors will annotate their code. I don't think people will=
annotate their code if the code works in most hosted environments without =
the annotation though. This ends up burdening the kernel / embedded user w=
ith auditing the code (which they have to do today), then updating the code=
to include the annotation (they don't need to do this today). So it ends =
in more work an awful lot of the time. Maybe I'm being pessimistic though,=
and there will be a rich set of libraries correctly annotated with no_floa=
t.
As I=E2=80=99ve said in a previous reply: we=E2=80=99ll implement and updat=
e a future paper with usage experience.
--=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/7A7106A5-5E07-4DC2-8D41-795C7DE5151D%40apple.com=
..
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Tue, 16 Oct 2018 19:52:41 -0700 (PDT)
Raw View
------=_Part_2397_1061563783.1539744761779
Content-Type: multipart/alternative;
boundary="----=_Part_2398_1739555246.1539744761779"
------=_Part_2398_1739555246.1539744761779
Content-Type: text/plain; charset="UTF-8"
On Tuesday, October 16, 2018 at 8:38:26 PM UTC-5, Thiago Macieira wrote:
>
> On Tuesday, 16 October 2018 18:22:34 PDT Ben Craig wrote:
> > How should vector, array, and other templates be annotated? Depending
> on
> > the type of T, they may be no_float or not.
>
> Before answering how, please explain why they should be annotated in the
> first
> place. What is the objective?
>
I guess I'm just really confused at this point. There's a no_float
attribute that is supposed to make things better for kernel and embedded
environments. At first, I thought that the compiler could use the
attribute to choose what compiles and what doesn't compile. I don't think
that's the case though, as the paper allows no_float to call float. The
prior comments in this thread have me confused as to whether the
annotations would cause the compiler to generate different code (i.e.
saving and restoring floating point registers). If that's the case, then
code needs to be annotated accurately so that floating point state can be
saved as little as possible.
So my objective with the question is to get a better understanding of what
this paper is trying to do.
>
> > In what way do you see this improving the developer experience? Could
> you
> > get the same benefit by dumping the disassembly of your binaries, and
> > searching for offending registers and instructions? On x64, the strings
> > "xmm", "ymm", and "zmm" don't show up too often, and developers could
> white
> > list the code where they have been super careful and used the FPU and
> > vector registers appropriately. I suspect the same could be done on
> arm,
> > just searching for the D# and Q# registers instead.
>
> That is not a good solution, leading to long-term code maintainability. A
> single change in a header you don't control can cause a previously unused
> optimisation to kick in or a previously used one to be dumped, changing
> the
> code generation and with it which registers get used. Not to mention of
> course
> that compilers improve too. You can't count on the code not using some
> instruction once as a guarantee it will never.
>
So you make the script part of your tests. Maybe even your unit tests, so
that it runs as part of a build. I'm doing just that in my kernel test
harness for my freestanding
work. https://github.com/ben-craig/kernel_test_harness . "ninja
check_asm" will dumpbin the binaries and run a little program on the output
looking for the offending text.
>
> > My concern with this annotation approach is that it assumes that most
> > module / function authors will annotate their code. I don't think
> people
> > will annotate their code if the code works in most hosted environments
> > without the annotation though. This ends up burdening the kernel /
> > embedded user with auditing the code (which they have to do today), then
> > updating the code to include the annotation (they don't need to do this
> > today). So it ends in more work an awful lot of the time. Maybe I'm
> being
> > pessimistic though, and there will be a rich set of libraries correctly
> > annotated with no_float.
>
> That was one of my points. It's much preferable for kernel developers to
> turn
> the use of SSE explicitly off and explicitly turn on only where allowed.
>
> --
> 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/6be4c5fa-eeb1-4580-8ea7-f67d78499e18%40isocpp.org.
------=_Part_2398_1739555246.1539744761779
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 16, 2018 at 8:38:26 PM UTC-5, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 16 O=
ctober 2018 18:22:34 PDT Ben Craig wrote:
<br>> How should vector, array, and other templates be annotated? =C2=A0=
Depending on
<br>> the type of T, they may be no_float or not.
<br>
<br>Before answering how, please explain why they should be annotated in th=
e first=20
<br>place. What is the objective?
<br></blockquote><div><br></div><div>I guess I'm just really confused a=
t this point.=C2=A0 There's a no_float attribute that is supposed to ma=
ke things better for kernel and embedded environments.=C2=A0 At first, I th=
ought that the compiler could use the attribute to choose what compiles and=
what doesn't compile.=C2=A0 I don't think that's the case thou=
gh, as the paper allows no_float to call float.=C2=A0 The prior comments in=
this thread have me confused as to whether the annotations would cause the=
compiler to generate different code (i.e. saving and restoring floating po=
int registers).=C2=A0 If that's the case, then code needs to be annotat=
ed accurately so that floating point state can be saved as little as possib=
le.</div><div><br></div><div>So my objective with the question is to get a =
better understanding of what this paper is trying to do.</div><div><br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> In what way do you see this improving the developer experience? =
=C2=A0Could you
<br>> get the same benefit by dumping the disassembly of your binaries, =
and
<br>> searching for offending registers and instructions? =C2=A0On x64, =
the strings
<br>> "xmm", "ymm", and "zmm" don't sh=
ow up too often, and developers could white
<br>> list the code where they have been super careful and used the FPU =
and
<br>> vector registers appropriately. =C2=A0I suspect the same could be =
done on arm,
<br>> just searching for the D# and Q# registers instead.
<br>
<br>That is not a good solution, leading to long-term code maintainability.=
A=20
<br>single change in a header you don't control can cause a previously =
unused=20
<br>optimisation to kick in or a previously used one to be dumped, changing=
the=20
<br>code generation and with it which registers get used. Not to mention of=
course=20
<br>that compilers improve too. You can't count on the code not using s=
ome=20
<br>instruction once as a guarantee it will never.
<br></blockquote><div>=C2=A0</div><div>So you make the script part of your =
tests.=C2=A0 Maybe even your unit tests, so that it runs as part of a build=
..=C2=A0 I'm doing just that in my kernel test harness for my freestandi=
ng work.=C2=A0=C2=A0https://github.com/ben-craig/kernel_test_harness .=C2=
=A0 "ninja check_asm" will dumpbin the binaries and run a little =
program on the output looking for the offending text.</div><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> My concern with this annotation approach is that it assumes that m=
ost
<br>> module / function authors will annotate their code. =C2=A0I don=
9;t think people
<br>> will annotate their code if the code works in most hosted environm=
ents
<br>> without the annotation though. =C2=A0This ends up burdening the ke=
rnel /
<br>> embedded user with auditing the code (which they have to do today)=
, then
<br>> updating the code to include the annotation (they don't need t=
o do this
<br>> today). =C2=A0So it ends in more work an awful lot of the time. =
=C2=A0Maybe I'm being
<br>> pessimistic though, and there will be a rich set of libraries corr=
ectly
<br>> annotated with no_float.
<br>
<br>That was one of my points. It's much preferable for kernel develope=
rs to turn=20
<br>the use of SSE explicitly off and explicitly turn on only where allowed=
..
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></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/6be4c5fa-eeb1-4580-8ea7-f67d78499e18%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6be4c5fa-eeb1-4580-8ea7-f67d78499e18=
%40isocpp.org</a>.<br />
------=_Part_2398_1739555246.1539744761779--
------=_Part_2397_1061563783.1539744761779--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 16 Oct 2018 21:45:46 -0700
Raw View
On Tuesday, 16 October 2018 19:52:41 PDT Ben Craig wrote:
> On Tuesday, October 16, 2018 at 8:38:26 PM UTC-5, Thiago Macieira wrote:
> > On Tuesday, 16 October 2018 18:22:34 PDT Ben Craig wrote:
> > > How should vector, array, and other templates be annotated? Depending
> >
> > on
> >
> > > the type of T, they may be no_float or not.
> >
> > Before answering how, please explain why they should be annotated in the
> > first
> > place. What is the objective?
>
> I guess I'm just really confused at this point. There's a no_float
> attribute that is supposed to make things better for kernel and embedded
> environments.
The attribute was proposed for functions. You're the one who brought
templates, arrays and vectors up. I am asking what you expect the attribute to
do there.
> At first, I thought that the compiler could use the
> attribute to choose what compiles and what doesn't compile. I don't think
> that's the case though, as the paper allows no_float to call float. The
> prior comments in this thread have me confused as to whether the
> annotations would cause the compiler to generate different code (i.e.
> saving and restoring floating point registers). If that's the case, then
> code needs to be annotated accurately so that floating point state can be
> saved as little as possible.
You're right, the paper did not specify that at all. There are two possible
solutions for a "yes_float" function called inside a no-float context:
1) use floating point emulation
2) enable the use of the FPU and later disable it
The paper needs to specify what it expects compilers to do.
> > That is not a good solution, leading to long-term code maintainability. A
> > single change in a header you don't control can cause a previously unused
> > optimisation to kick in or a previously used one to be dumped, changing
> > the
> > code generation and with it which registers get used. Not to mention of
> > course
> > that compilers improve too. You can't count on the code not using some
> > instruction once as a guarantee it will never.
>
> So you make the script part of your tests. Maybe even your unit tests, so
> that it runs as part of a build. I'm doing just that in my kernel test
> harness for my freestanding
> work. https://github.com/ben-craig/kernel_test_harness . "ninja
> check_asm" will dumpbin the binaries and run a little program on the output
> looking for the offending text.
That doesn't sound practical to me. Suppose you do find the compiler generated
code you don't want: what do you do? Change the code at random? Insert some
printf() that you don't need?
No, testing is good, but you need a way to tell the compiler to obey you. The
paper has the right intentions, but I don't think it should be in the
standard. It's awfully compiler-specific.
--
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/2689428.foJyBWMgKY%40tjmaciei-mobl1.
.
Author: John McFarlane <john@mcfarlane.name>
Date: Wed, 17 Oct 2018 07:06:26 +0000
Raw View
--000000000000bd12540578674e8d
Content-Type: text/plain; charset="UTF-8"
On Tue, 16 Oct 2018 at 16:55 JF Bastien <jfbastien@apple.com> wrote:
>
> On Oct 16, 2018, at 2:34 AM, Ivan G. <nekotekina@gmail.com> wrote:
>
> I think the attribute should be named [[gpr_only]], meaning that the
> function uses only general-purpose registers.
>
>
> We can bikeshed in EWG (or other venue which sees the paper).
>
Why not this venue? Are you suggesting we should defer bikeshed until
in-person meetings? I'd prefer it if more, not less, decision making was
done in advance.
John
--
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/CABPJVnQ0OtVLnDGd6xFFnwegR3apofmWtriu1-OFKVvFTPi%3D6g%40mail.gmail.com.
--000000000000bd12540578674e8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 16 Oct=
2018 at 16:55 JF Bastien <<a href=3D"mailto:jfbastien@apple.com">jfbast=
ien@apple.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word;line-break:after-white-space"><div><br><blockq=
uote type=3D"cite"><div>On Oct 16, 2018, at 2:34 AM, Ivan G. <<a href=3D=
"mailto:nekotekina@gmail.com" target=3D"_blank">nekotekina@gmail.com</a>>=
; wrote:</div><br></blockquote></div></div><div style=3D"word-wrap:break-wo=
rd;line-break:after-white-space"><div><blockquote type=3D"cite"><div><div d=
ir=3D"ltr"><div>I think the attribute should be named [[gpr_only]], meaning=
that the function uses only general-purpose registers.</div></div></div></=
blockquote><div><br></div></div></div><div style=3D"word-wrap:break-word;li=
ne-break:after-white-space"><div><div>We can bikeshed in EWG (or other venu=
e which sees the paper).</div></div></div></blockquote><div><br></div><div>=
Why not this venue? Are you suggesting we should defer bikeshed until in-pe=
rson meetings? I'd prefer it if more, not less, decision making was don=
e in advance.</div><div><br></div><div>John</div><br></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/CABPJVnQ0OtVLnDGd6xFFnwegR3apofmWtriu=
1-OFKVvFTPi%3D6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ0OtVLnD=
Gd6xFFnwegR3apofmWtriu1-OFKVvFTPi%3D6g%40mail.gmail.com</a>.<br />
--000000000000bd12540578674e8d--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 17 Oct 2018 07:13:38 -0700 (PDT)
Raw View
------=_Part_2752_2146956373.1539785618831
Content-Type: multipart/alternative;
boundary="----=_Part_2753_1018614646.1539785618832"
------=_Part_2753_1018614646.1539785618832
Content-Type: text/plain; charset="UTF-8"
>
> > > That is not a good solution, leading to long-term code
> maintainability. A
> > > single change in a header you don't control can cause a previously
> unused
> > > optimisation to kick in or a previously used one to be dumped,
> changing
> > > the
> > > code generation and with it which registers get used. Not to mention
> of
> > > course
> > > that compilers improve too. You can't count on the code not using some
> > > instruction once as a guarantee it will never.
> >
> > So you make the script part of your tests. Maybe even your unit tests,
> so
> > that it runs as part of a build. I'm doing just that in my kernel test
> > harness for my freestanding
> > work. https://github.com/ben-craig/kernel_test_harness . "ninja
> > check_asm" will dumpbin the binaries and run a little program on the
> output
> > looking for the offending text.
>
> That doesn't sound practical to me. Suppose you do find the compiler
> generated
> code you don't want: what do you do? Change the code at random? Insert
> some
> printf() that you don't need?
>
> No, testing is good, but you need a way to tell the compiler to obey you.
> The
> paper has the right intentions, but I don't think it should be in the
> standard. It's awfully compiler-specific.
>
You are right that you do need to set the right compiler flags in the first
place. In particular, you probably need to have auto-vectorization turned
off, as otherwise you will have the kinds of optimization instability you
are referring to. With MSVC /KERNEL gets the job done.
Inspecting the assembly is useful for finding places developers / compilers
missed. In environments like the some kernels where floating point is
allowed in certain situations with great care, the compiler may not warn
when you use a float. Searching the assembly will flag those places and
tell you which function it happened in, even if that usage was in some
distant library that you don't have the source for.
--
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/875ae434-9fdc-4dd5-9a12-cddc8815087b%40isocpp.org.
------=_Part_2753_1018614646.1539785618832
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">> > That is not a good s=
olution, leading to long-term code maintainability. A
<br>> > single change in a header you don't control can cause a p=
reviously unused
<br>> > optimisation to kick in or a previously used one to be dumped=
, changing
<br>> > the
<br>> > code generation and with it which registers get used. Not to =
mention of
<br>> > course
<br>> > that compilers improve too. You can't count on the code n=
ot using some
<br>> > instruction once as a guarantee it will never.
<br>>=20
<br>> So you make the script part of your tests. =C2=A0Maybe even your u=
nit tests, so
<br>> that it runs as part of a build. =C2=A0I'm doing just that in =
my kernel test
<br>> harness for my freestanding
<br>> work. =C2=A0<a href=3D"https://github.com/ben-craig/kernel_test_ha=
rness" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fben-craig%2Fkerne=
l_test_harness\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjXZogIY7Y2O0Z427kzH=
NOWhXFVQ';return true;" onclick=3D"this.href=3D'https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fben-craig%2Fkernel_test_harness\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjXZogIY7Y2O0Z427kzHNOWhXFVQ';retu=
rn true;">https://github.com/ben-craig/<wbr>kernel_test_harness</a> . =C2=
=A0"ninja
<br>> check_asm" will dumpbin the binaries and run a little program=
on the output
<br>> looking for the offending text.
<br>
<br>That doesn't sound practical to me. Suppose you do find the compile=
r generated=20
<br>code you don't want: what do you do? Change the code at random? Ins=
ert some=20
<br>printf() that you don't need?
<br>
<br>No, testing is good, but you need a way to tell the compiler to obey yo=
u. The=20
<br>paper has the right intentions, but I don't think it should be in t=
he=20
<br>standard. It's awfully compiler-specific.
<br></blockquote><div><br></div><div>You are right that you do need to set =
the right compiler flags in the first place.=C2=A0 In particular, you proba=
bly need to have auto-vectorization turned off, as otherwise you will have =
the kinds of optimization instability you are referring to.=C2=A0 With MSVC=
/KERNEL gets the job done.</div><div><br></div><div>Inspecting the assembl=
y is useful for finding places developers / compilers missed.=C2=A0 In envi=
ronments like the some kernels where floating point is allowed in certain s=
ituations with great care, the compiler may not warn when you use a float.=
=C2=A0 Searching the assembly will flag those places and tell you which fun=
ction it happened in, even if that usage was in some distant library that y=
ou don't have the source for.=C2=A0</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/875ae434-9fdc-4dd5-9a12-cddc8815087b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/875ae434-9fdc-4dd5-9a12-cddc8815087b=
%40isocpp.org</a>.<br />
------=_Part_2753_1018614646.1539785618832--
------=_Part_2752_2146956373.1539785618831--
.