[std-proposals] P1246R0: The no_float function attribute

[Thiago Macieira]

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

[David Brown]

Post by Thiago Macieira
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.
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.

Post by Thiago Macieira
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.)

Post by Thiago Macieira
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 ?

[Gašper Ažman]

[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

[Thiago Macieira]

[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.

Attributes are not allowed to change the visible behaviour, but they are
intended to help the compiler optimise the code better. See [[noreturn]] for
an example. So a [[no_float]] attribute could let the compiler optimise by not
performing any caller-saved FP saving, as it knows the called function will
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]] function
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
must save the caller-saved registers. Since the [[no_float]] says it won't
touch them, it stands to reason that the callee takes on that responsibility.

In fact, that's what kernels usually do: they have a pair of functions or
macros that must be called before and after any FP-using code to save the
context from the user and then restore it.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

Post by David Brown

Post by Thiago Macieira
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.

Post by David Brown
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

[JF Bastien]

Post by Thiago Macieira
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.
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”?

See wg21.link/P1245R0 <http://wg21.link/P1245R0> for how we see this working. We also expect that particular targets would warn if the attribute isn’t present, or something like clang-tidy would be used.

Post by Thiago Macieira
2) if there's a TU-wide marker, should there be an inverse attribute
"yes_float" (with a better name)?

Yes.

Post by Thiago Macieira
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?

We can bikeshed at will.

Post by Thiago Macieira
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

[Arthur O'Dwyer]

Post by Thiago Macieira
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.

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.

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
precious San Diego time discussing P1246 in its current state. (But P1245,
as I said, seems like a fine idea.)

my $.02,
–Arthur

[JF Bastien]

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>
The paper proposes a new function attribute to prevent the generation of
floating point instructions by the compiler, clearly marking such a function.
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.
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 precious San Diego time discussing P1246 in its current state. (But P1245, as I said, seems like a fine idea.)

We’ll implement it, worry not. Just haven’t gotten around to it. We have concrete motivation for it, and again today I wish we had the attribute.

Don’t worry, EWG won’t spend time on this paper in San Diego :-)
In fact, this paper will be a role model in how it’s treated in San Diego!

[Ivan G.]

It seems the primary motivation for this attribute is having a calling
convention which guarantees that SIMD registers will not be modified.

But SIMD registers usually work not only with floating point values, but
with packed integral values as well, which raises many questions.

I think the attribute should be named [[gpr_only]], meaning that the
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
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.

Maybe even doing the computation involving them is still possible, if the
extended state is preserved. Just save all the modified non-general-purpose
registers and restore them. Although it seems hard to arbitrarily save AVX
state on x86.

Post by Arthur O'Dwyer

Post by Thiago Macieira
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.

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.
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
precious San Diego time discussing P1246 in its current state. (But P1245,
as I said, seems like a fine idea.)
We’ll implement it, worry not. Just haven’t gotten around to it. We have
concrete motivation for it, and again today I wish we had the attribute.
Don’t worry, EWG won’t spend time on this paper in San Diego :-)
In fact, this paper will be a role model in how it’s treated in San Diego!

[JF Bastien]

It seems the primary motivation for this attribute is having a calling convention 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 explicitly. Doesn’t matter if it’s FP or integers.

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).

This can be meaningful for many architectures, not only x86.

Yes.

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.

Maybe even doing the computation involving them is still possible, if the extended state is preserved. Just save all the modified non-general-purpose registers and restore them. Although it seems hard to arbitrarily save AVX state on x86.

That’s not acceptable in the use cases we’re trying to meet.

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>
The paper proposes a new function attribute to prevent the generation of
floating point instructions by the compiler, clearly marking such a function.
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.
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 precious San Diego time discussing P1246 in its current state. (But P1245, as I said, seems like a fine idea.)

We’ll implement it, worry not. Just haven’t gotten around to it. We have concrete motivation for it, and again today I wish we had the attribute.
Don’t worry, EWG won’t spend time on this paper in San Diego :-)
In fact, this paper will be a role model in how it’s treated in San Diego!

[Thiago Macieira]

Post by JF Bastien

Post by Ivan G.
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

[John McFarlane]

Post by Ivan G.
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

[Myriachan]

Post by Arthur O'Dwyer
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.

[Ben Craig]

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.

[Thiago Macieira]

Post by Ben Craig
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?

Post by Ben Craig
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.

Post by Ben Craig
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

[Ben Craig]

Post by Thiago Macieira

Post by Ben Craig
How should vector, array, and other templates be annotated? Depending

on

Post by Ben Craig
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.

Post by Thiago Macieira

Post by Ben Craig
In what way do you see this improving the developer experience? Could

you

Post by Ben Craig
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

Post by Ben Craig
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,

Post by Ben Craig
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.

Post by Thiago Macieira

Post by Ben Craig
My concern with this annotation approach is that it assumes that most
module / function authors will annotate their code. I don't think

people

Post by Ben Craig
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

Post by Ben Craig
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

[Thiago Macieira]

Post by Ben Craig

Post by Thiago Macieira

Post by Ben Craig
How should vector, array, and other templates be annotated? Depending

on

Post by Ben Craig
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.

Post by Ben Craig
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.

Post by Ben Craig

Post by Thiago Macieira
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

[Ben Craig]

Post by Thiago Macieira

Post by Ben Craig

Post by Thiago Macieira
That is not a good solution, leading to long-term code

maintainability. A

Post by Ben Craig

Post by Thiago Macieira
single change in a header you don't control can cause a previously

unused

Post by Ben Craig

Post by Thiago Macieira
optimisation to kick in or a previously used one to be dumped,

changing

Post by Ben Craig

Post by Thiago Macieira
the
code generation and with it which registers get used. Not to mention

of

Post by Ben Craig

Post by Thiago Macieira
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

Post by Ben Craig
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

Post by Ben Craig
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.

[JF Bastien]

How should vector, array, and other templates be annotated? Depending on the type of T, they may be no_float or not.

Don’t annotate them. The type of code this is useful for is often pretty much C code, with very few such dependencies.

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?

From experience, this isn’t done. It’s also way better to have the compiler tell you that you messed up than have some random tool do so. The attribute document expectations for this function. This is traditionally enforced with a comment, and comments have very little bearing with reality.

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.

As I’ve said in a previous reply: we’ll implement and update a future paper with usage experience.

[p***@lib.hu]

To me the whole proposal looks very niche. But the main point I don't get

3. Other functions that use floating-point types can be called from one

marked with the no_float attribute as long as the callee’s parameters and
return type aren’t floating-point.

With that how and what is helped? The rest suggests wanting to make the
body free from touching any FP and leave the state at found. If the body
has 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 attribute, then what is the point of the attribute?

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).

[JF Bastien]

3. Other functions that use floating-point types can be called from one marked with the no_float attribute as long as the callee’s parameters and return type aren’t floating-point.

With that how and what is helped? The rest suggests wanting to make the body free from touching any FP and leave the state at found. If the body has 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 attribute, then what is the point of the attribute?

You can’t 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).